HP DNS Configuration and Management Manual

Transcription

1 HP DNS Configuration and Management Manual Abstract This manual describes how to implement Domain Name System (DNS) on the HP NonStop in the HP NonStop Open System Services (OSS) environment. This manual is intended for network administrators responsible for managing DNS. Product Version DNS DNS 9.3 Supported Release Version Updates (RVUs) This publication supports G06.27 and all subsequent G-series RVUs and H06.05 and all subsequent H-series RVUs until otherwise indicated by its replacement publication. Part Number Published February 2006

2 Document History Part Number Product Version Published DNS 9.2.3, DNS 9.3 December DNS 9.2.3, DNS 9.3 September DNS 9.2.3, DNS 9.3 February 2006

3 HP DNS Configuration and Management Manual Glossary Index Examples Figures Tables What s New in This Manual vii Manual Information vii New and Changed Information vii About This Manual ix Manual Organization ix Statement for Ported Software and Related Documentation Related Manuals x Additional Resources xi Notation Conventions xiii Abbreviations xvii x 1. Quick Start Prepare to Start DNS 1-1 Check Assumptions Before Starting DNS 1-1 Start DNS 1-2 Start Nonsecure DNS Using the Default Options 1-2 Start Secure DNS With Default Options 1-3 Stop DNS BIND 9.x on the NonStop Server DNS and BIND 9.x on the NonStop Server 2-1 Product IDs 2-1 Features 2-1 System Requirements 2-2 Restrictions 2-2 Assumptions and Dependencies 2-2 Running DNS in the Open System Services (OSS) Environment 2-2 DNS Tools and Utilities 2-4 Dynamic Update 2-4 rndc 2-7 Incremental Zone Transfer (IXFR) 2-9 dig 2-11 Hewlett-Packard Company i

4 Contents 2. BIND 9.x on the NonStop Server (continued) 2. BIND 9.x on the NonStop Server (continued) DNS Tools and Utilities (continued) named-bootconf 2-12 nsupdate 2-12 DNS Security Extensions (DNSSEC) Tools 2-13 IPv6 Address Support 2-14 Application Programmatic Interface (API) for DNS DNS Configuration on the NonStop Server Starting the named Demon 3-1 Using the Lightweight Resolver 3-1 Lightweight Resolver demon 3-2 Compiling Existing DNS Applications to Use the Lightweight Resolver Library 3-2 Understanding DNS Security Threats 3-3 Local Threats 3-4 Zone Transfer Threat 3-5 Dynamic Update Threat 3-6 Remote Query Threat 3-7 Remote Caching Corruption Threat 3-8 Implementing DNS Security Solutions 3-8 Use ACLs 3-9 Conceal the BIND Version 3-15 Protect the Configuration File: Restrict the Privilege of named and Run It in a chroot-jail 3-15 Use TSIG 3-16 Configure Views 3-18 Use Firewalls and a Bastion Host 3-19 Use Public Key Cryptography: DNSSEC 3-20 Managing Persistence for the named Process 3-22 Configuring the named Process as a Persistent Process 3-22 Stopping the named Process as a Persistent Process 3-23 Specifying a TCP/IP Process by Using a Runtime Option 3-23 Specifying a Different resolv.conf File 3-23 Specifying Multiple Names in the Resolver by Using Sections 3-24 Tips and Important Tasks 3-26 ii

5 Contents 4. Scaling DNS 4. Scaling DNS Physical Network Separation 4-1 DNS Round-Robin Address Rotation Troubleshooting Troubleshooting DNS 5-1 Logging in DNS 5-3 A. DNS and BIND Basics Components of DNS A-1 DNS Name Space A-1 The Resolver A-3 The Name Server A-3 Lightweight Resolver Library and Demon A-4 How BIND Works A-4 Overview A-4 The Resolution Process A-6 The BIND Configuration File A-18 The /etc/named.conf Statements A-18 B. DNS Server Configuration Master Server Configuration File B-1 Master Server Cache File B-4 The db File B-8 Master Server db.domain Files B-10 Glossary Index Examples Example 2-1. Zone File With allow-update 2-6 Example 2-2. rndc Command 2-9 Example 2-3. Setting the Server Statement to Disable IXFR 2-10 Example 2-4. Setting the Server Statement in the Configuration File 2-10 Example 2-5. Using dig 2-11 Example 2-6. Obtain the Latest List of Root Domain Servers 2-11 Example 2-7. Find the Name Servers for a Zone 2-11 Example 2-8. Request all Records for a Zone From an Authoritative Server 2-11 Example 2-9. Look Up the Domain Name Corresponding to an IP Address 2-12 iii

6 Contents Examples (continued) Examples (continued) Example Migrating the Configuration File 2-12 Example Using the nsupdate Tool 2-13 Example dnssec-keygen 2-13 Example dnssec-signzone 2-14 Example Setting named to Listen on IPv6 Interfaces 2-15 Example Setting the IPv6 Address for Notify Messages 2-15 Example 3-1. Starting named 3-1 Example 3-2. Configuring ACL Security (named.conf) 3-12 Example 3-3. Sample Configuration File for Views 3-19 Example 3-4. Specifying a Different resolv.conf File Through an Application 3-24 Example 3-5. Specifying a Different resolv.conf File Through the OSS Shell 3-24 Example 3-6. Resolver Configuration File With Sections 3-25 Example 5-1. Sample named.conf File 5-2 Example 5-2. Logging Statement in named.conf File 5-4 Example B-1. Configuration File for Master Server Authoritative for Domain div.inc.com and Network B-2 Example B-2. named.conf Sample File B-3 Example B-3. Sample db.domain File B-10 Figures Figure 3-1. Local File Update Threat From File Corruption 3-4 Figure 3-2. Zone Transfer Threat, IP Address Spoofing 3-5 Figure 3-3. Dynamic Update Threat 3-6 Figure 3-4. Remote Query Threat, Server to Client 3-7 Figure 3-5. Remote Caching Corruption Threat, Client to Client 3-8 Figure 3-6. ACL Example: Internet 3-11 Figure 3-7. ACL Example: Restricting Zone Transfers 3-14 Figure 3-8. Updates Secured Through TSIG 3-16 Figure 4-1. Physical Separation of Network Traffic 4-2 Figure 4-2. DNS Round-Robin Address Rotation 4-3 Figure 5-1. Logging Categories to Channels 5-4 Figure A-1. Structure of the DNS Name Space A-2 Figure A-2. Recursive Query Is Sent by the Client Resolver A-9 Figure A-3. Local Name Server Receives Recursive Query A-10 Figure A-4. Name Server Sends Nonrecursive Query to Root A-11 Figure A-5. Root Server Refers Local Name Server to a Closer Server A-12 Figure A-6. Local Name Server Sends Query to Referred Server A-13 Figure A-7. The Next Server Refers Local Server to Next Closer Server A-14 iv

7 Contents Figures (continued) Figures (continued) Tables Figure A-8. Local Server Sends Query to Next Referred Server A-15 Figure A-9. Authoritative Server Returns IP Address to Local Server A-16 Figure A-10. Local Server Answers Original Request A-17 Figure A-11. Client Resolver Receives IP Address of Requested Server A-18 Figure B-1. Structure of a Master Server and Slave Servers B-2 Table i. Manual Organization ix Table ii. OSS Manuals x Table 2-1. OSS Commands to Access man Pages 2-3 Table 2-2. Files for Nonsecure and Secure DNS Products 2-4 Table 2-3. rndc Commands 2-7 Table 3-1. DNS Security Threats 3-3 Table 3-2. Possible Solutions for DNS Security Threats* 3-9 v

8 Contents vi

9 What s New in This Manual Manual Information Abstract HP DNS Configuration and Management Manual This manual describes how to implement Domain Name System (DNS) on the HP NonStop in the HP NonStop Open System Services (OSS) environment. This manual is intended for network administrators responsible for managing DNS. Product Version DNS DNS 9.3 Supported Release Version Updates (RVUs) This publication supports G06.27 and all subsequent G-series RVUs and H06.05 and all subsequent H-series RVUs until otherwise indicated by its replacement publication. Part Number Published February 2006 Document History Part Number Product Version Published DNS 9.2.3, DNS 9.3 December DNS 9.2.3, DNS 9.3 September DNS 9.2.3, DNS 9.3 February 2006 New and Changed Information For easy reference, change descriptions for all additions are included in this subsection. Only changes for this version are indicated with change bars in the content, however. Changes Made for The manual has been updated to reflect support for the HP Integrity NonStop NS-series and the H-series RVUs. This minor change is reflected in the supported RVU statements and throughout the text wherever s and RVUs are referred to. vii

10 What s New in This Manual Changes Made for Changes Made for The manual was updated to include new features for DNS 9.3 and to provide more background information about DNS in general. The procedure Stopping the named Process as a Persistent Process on page 3-23 was corrected. The procedure Configuring the named Process as a Persistent Process on page 3-22 was corrected. Changes Made for This was the first version of this manual. viii

11 About This Manual This manual describes how to implement the Domain Name System (DNS) on the NonStop Server in the HP NonStop Open System Services (OSS) environment. For general information about BIND 9.x, see the BIND 9 Administrator Reference Manual in the NonStop Technical Library (NTL). This section contains the following information: Manual Organization on page ix Statement for Ported Software and Related Documentation on page x Related Manuals on page x Additional Resources on page xi Notation Conventions on page xiii Abbreviations on page xvii Manual Organization DNS administration is a complex topic; this manual emphasizes some of the newer aspects of DNS such as security features as well as NonStop specific information. For convenience, some DNS basic information is included in the appendixes. Table i. Manual Organization Section Section 1, Quick Start Section 2, BIND 9.x on the NonStop Server Section 3, DNS Configuration on the NonStop Server Section 4, Scaling DNS Section 5, Troubleshooting Appendix A, DNS and BIND Basics Appendix B, DNS Server Configuration Glossary Description Provides examples of starting DNS and stopping DNS. Provides a brief introduction to BIND 9.x and DNS on the NonStop, including restrictions, assumptions, and tools. Provides configuration and management information for DNS, including persistence, security, tools use, resolv.conf file specification, transport provider service specification, section specification, and a list of tips and important tasks. Provides procedures for scaling your named process. Provides logging procedures and troubleshooting tips. Provides basic DNS information such as the resolution process and more information about BIND components and files. Provides examples of configuring a master configuration file. Defines terms used in the manual. ix

12 About This Manual Statement for Ported Software and Related Documentation Statement for Ported Software and Related Documentation (C) Copyright 2000, 2001 Internet Software Consortium. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Related Manuals Many resources exist to help you operate in the OSS environment. Table i lists the tasks that you may need to perform and the suggested resources to assist you in those tasks. These manuals are all available in the NonStop Technical Library (NTL). Table ii. OSS Manuals Task Installing OSS Managing files Accessing man pages Running OSS processes from the Guardian environment Application programmatic interface Using the VI editor in OSS Manual Title Open System Services Installation Guide Open System Services Management and Operations Guide Open System Services Management and Operations Guide Open System Services User s Guide and Open System Services Shell and Utilities Reference Manual Open System Services Library Calls Reference Manual and TCP/IP Programming Manual Open System Services User s Guide For information about accessing the OSS man pages, see DNS and BIND 9.x on the NonStop Server on page 2-1. x

13 About This Manual About the BIND 9 Administrator Reference Manual About the BIND 9 Administrator Reference Manual The BIND 9 Administrator Reference Manual provides basic information about the concepts and management of the Internet Software Consortium (ISC) BIND version 9 software package for system administrators, and includes the following topics: Introduction to basic DNS and BIND concepts More advanced concepts that may be needed for implementing certain options A reference section to aid in the ongoing maintenance of the software Security considerations and troubleshooting help Domain Name Security Extensions (DNSSEC) Lightweight Resolver Other Resources DNS and BIND 4th edition by Paul Albitz and Cricket Liu, published by O Reilly and Associates, Inc. DNS and BIND Cookbook by Cricket Liu, published by O Reilly and Associates, Inc. DNS Open Source Guide DNS Security Extensions (DNSSEC) DNS and BIND Resources Comprehensive DNS Tools Quick check of your zone files Internet Systems Consortium Additional Resources In addition to the Web resources, books, and manuals, the man pages provide further documentation about specific tools and files, and the RFCs provide the source material for the whole DNS. Of particular relevance and highly recommended, is RFC 3833, described below. If you are implementing security, read RFC 3833 for an excellent analysis of DNS security threats and the limitations of DNSSEC and other counterattack strategies. man pages man pages are provided for DNS in the OSS environment. For information about accessing the man pages, see Table 2-1, OSS Commands to Access man Pages, on page 2-3. xi

14 About This Manual RFCs RFCs All of the following DNS RFCs may be found at RFC 1034 Domain names - concepts and facilities RFC 1035 Domain names - implementation and specification RFC 1101 DNS Encoding of Network Names and Other Types RFC 1183 New DNS RR Definitions RFC 1591 Domain Name System Structure and Delegation RFC 1886 DNS Extensions to support IP version 6 RFC 1912 Common DNS Operational and Configuration Errors RFC 1995 Incremental Zone Transfer in DNS RFC 1996 A Mechanism for Prompt Notification of Zone Changes RFC 2136 Dynamic Updates in the Domain Name System RFC 2181 Clarifications to the DNS Specification RFC 2317 Classless IN-ADDR.ARPA delegation RFC 2535 Domain Name System Security Extensions RFC 2606 Reserved Top Level DNS Names RFC 2671 Extension Mechanisms for DNS RFC 2672 Non Terminal DNS Name Redirection RFC 2673 Binary Labels in the Domain Name System RFC 2782 A DNS RR for specifying the location of services (DNS SRV) RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) RFC 2915 The Naming Authority Pointer (NAPTR) RFC 2916 E.164 number and DNS RFC 2929 Domain Name System (DNS) IANA Considerations RFC 2930 Secret Key Establishment for DNS RFC 3007 Secure Domain Name System RFC 3008 Domain Name System Security (DNSSEC) Signing Authority RFC 3090 DNS Security Extension Clarification on Zone Status xii

15 About This Manual Notation Conventions RFC 3110 RSA/SHA-1 SIGs and RSA keys in the Domain Name System RFC 3226 DNSSEC and IPv6 A6 aware /resolver message size RFC 3445 Limiting the Scope of the KEY Resource Record (RR) RFC 3658 Delegation Signer (DS) Resource Record (RR) RFC 3833 Threat Analysis of the Domain Name System (DNS) Notation Conventions Hypertext Links Blue underline is used to indicate a hypertext link within text. By clicking a passage of text with a blue underline, you are taken to the location described. For example: This requirement is described under Backup DAM Volumes and Physical Disk Drives on page 3-2. General Syntax Notation This list summarizes the notation conventions for syntax presentation in this manual. UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words. Type these items exactly as shown. Items not enclosed in brackets are required. For example: MAXATTACH lowercase italic letters. Lowercase italic letters indicate variable items that you supply. Items not enclosed in brackets are required. For example: file-name computer type. Computer type letters within text indicate C and Open System Services (OSS) keywords and reserved words. Type these items exactly as shown. Items not enclosed in brackets are required. For example: myfile.c italic computer type. Italic computer type letters within text indicate C and Open System Services (OSS) variable items that you supply. Items not enclosed in brackets are required. For example: pathname [ ] Brackets. Brackets enclose optional syntax items. For example: TERM [\system-name.]$terminal-name INT[ERRUPTS] xiii

16 About This Manual General Syntax Notation A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list can be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: FC [ num ] [ -num ] [ text ] K [ X D ] address { } Braces. A group of items enclosed in braces is a list from which you are required to choose one item. The items in the list can be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example: LISTOPENS PROCESS { $appl-mgr-name } { $process-name } ALLOWSU { ON OFF } Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example: INSPECT { OFF ON SAVEABEND } Ellipsis. An ellipsis immediately following a pair of brackets or braces indicates that you can repeat the enclosed sequence of syntax items any number of times. For example: M address [, new-value ] [ - ] { } An ellipsis immediately following a single syntax item indicates that you can repeat that syntax item any number of times. For example: "s-char " Punctuation. Parentheses, commas, semicolons, and other symbols not previously described must be typed as shown. For example: error := NEXTFILENAME ( file-name ) ; LISTOPENS SU $process-name.#su-name Quotation marks around a symbol such as a bracket or brace indicate the symbol is a required character that you must type as shown. For example: "[" repetition-constant-list "]" Item Spacing. Spaces shown between items are required unless one of the items is a punctuation symbol such as a parenthesis or a comma. For example: CALL STEPMOM ( process-id ) ; xiv

17 About This Manual Notation for Messages If there is no space between two items, spaces are not permitted. In this example, no spaces are permitted between the period and any other items: $process-name.#su-name Line Spacing. If the syntax of a command is too long to fit on a single line, each continuation line is indented three spaces and is separated from the preceding line by a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections. For example: ALTER [ / OUT file-spec / ] LINE [, attribute-spec ]!i and!o. In procedure calls, the!i notation follows an input parameter (one that passes data to the called procedure); the!o notation follows an output parameter (one that returns data to the calling program). For example: CALL CHECKRESIZESEGMENT ( segment-id!i, error ) ;!o!i,o. In procedure calls, the!i,o notation follows an input/output parameter (one that both passes data to the called procedure and returns data to the calling program). For example: error := COMPRESSEDIT ( filenum ) ;!i,o!i:i. In procedure calls, the!i:i notation follows an input string parameter that has a corresponding parameter specifying the length of the string in bytes. For example: error := FILENAME_COMPARE_ ( filename1:length!i:i, filename2:length ) ;!i:i!o:i. In procedure calls, the!o:i notation follows an output buffer parameter that has a corresponding input parameter specifying the maximum length of the output buffer in bytes. For example: error := FILE_GETINFO_ ( filenum!i, [ filename:maxlen ] ) ;!o:i Notation for Messages This list summarizes the notation conventions for the presentation of displayed messages in this manual. Bold Text. Bold text in an example indicates user input typed at the terminal. For example: ENTER RUN CODE?123 CODE RECEIVED: The user must press the Return key after typing the input. xv

18 About This Manual Notation for Messages Nonitalic text. Nonitalic letters, numbers, and punctuation indicate text that is displayed or returned exactly as shown. For example: Backup Up. lowercase italic letters. Lowercase italic letters indicate variable items whose values are displayed or returned. For example: p-register process-name [ ] Brackets. Brackets enclose items that are sometimes, but not always, displayed. For example: Event number = number [ Subject = first-subject-value ] A group of items enclosed in brackets is a list of all possible items that can be displayed, of which one or none might actually be displayed. The items in the list can be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: proc-name trapped [ in SQL in SQL file system ] { } Braces. A group of items enclosed in braces is a list of all possible items that can be displayed, of which one is actually displayed. The items in the list can be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines. For example: obj-type obj-name state changed to state, caused by { Object Operator Service } process-name State changed from old-objstate to objstate { Operator Request. } { Unknown. } Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example: Transfer status: { OK Failed } % Percent Sign. A percent sign precedes a number that is not in decimal notation. The % notation precedes an octal number. The %B notation precedes a binary number. The %H notation precedes a hexadecimal number. For example: % %B %H2F P=%p-register E=%e-register xvi

19 About This Manual Change Bar Notation Change Bar Notation Change bars are used to indicate substantive differences between this manual and its preceding version. Change bars are vertical rules placed in the right margin of changed portions of text, figures, tables, examples, and so on. Change bars highlight new or revised information. For example: The message types specified in the REPORT clause are different in the COBOL environment and the Common Run-Time Environment (CRE). The CRE has many new message types and some new message type codes for old message types. In the CRE, the message type SYSTEM includes all messages except LOGICAL-CLOSE and LOGICAL-OPEN. Abbreviations BIND. Berkeley Internet Name Domain DNS. Domain Name System ISC. Internet Systems Consortium IXFR. Incremental Zone Transfer OSS. Open System Services RNDC. Remote Name Demon Control (In this manual and in the OSS documentation, demon is used instead of daemon. ) xvii

20 About This Manual Abbreviations xviii

21 1 Quick Start This section provides examples of preparing to start Domain Name System (DNS), starting DNS, and stopping DNS. This section does not provide background information about DNS or the TCP/IP subsystems. Refer to the following manuals (located in NTL) to gain a more in-depth understanding of DNS, NonStop TCP/IP, Parallel Library TCP/IP, and NonStop TCP/IPv6: BIND 9 Administrator Reference Manual TCP/IPv6 Configuration and Management Manual TCP/IP (Parallel Library) Configuration and Management Manual NonStop TCP/IP Configuration and Management Manual Also see Section 2, BIND 9.x on the NonStop Server and the appendixes for background information about and examples of DNS. This section provides the following procedures: Prepare to Start DNS on page 1-1 Start DNS on page 1-2 Stop DNS on page 1-3 Prepare to Start DNS Check Assumptions Before Starting DNS Before starting DNS, ensure that these assumptions are met: The Open System Services (OSS) operating system is available. Refer to the Open System Services Installation Guide in NTL for installation procedures, and the Open System Services Management and Operations Guide in NTL for operating procedures. Nonsecure DNS or secure DNS is installed. To check that DNS is installed, perform the following steps: 1. For nonsecure DNS, change the directory to /etc/dns923/ in the OSS shell: Note. In this manual, the dollar sign ($) denotes the OSS shell prompt. $ cd /etc/dns923/ 2. For secure DNS, change the directory to /etc/dns_secure/ in the OSS shell: >cd /etc/dns_secure/ 1-1

22 Quick Start Start DNS 3. List the files in the directory by typing the following command: /etc/dns923>ls -al You should see a display that shows a list of DNS files along with their permissions. NonStop TCP/IP, Parallel Library TCP/IP, or NonStop TCP/IPv6 is running. If you plan to use IPv6 communications, verify that NonStop TCP/IPv6 is running in DUAL or INET6 mode; refer to the TCP/IPv6 Configuration and Management Manual in NTL for more information. You are logged in using the super ID (equivalent to a UNIX root user). You have planned your DNS implementation. You have configured the DNS files. See Section 3, DNS Configuration on the NonStop Server and the appendixes. Start DNS This subsection shows you how to start nonsecure or secure DNS using the default options, which is the simplest way of starting the named process. The zone files are automatically loaded from the location specified in the named.conf file, which is looked up, by default, in /etc. Because the named.conf file is located in the /etc/dns923/ or /etc/dns_secure/ directory in OSS, by default, you must use the -c option with the named command to direct the program to look in the correct directory for the configuration file. Start Nonsecure DNS Using the Default Options 1. Log on and switch to the OSS shell by typing OSH at the TACL prompt: >OSH 2. Change directories to the nonsecure DNS directory: $ cd /etc/dns923/ 3. Start named by typing the following command: $ named -c /etc/dns923/named.conf 4. To check that the named process is running, type: $ ps more 1-2

23 Quick Start Start Secure DNS With Default Options Start Secure DNS With Default Options 1. Log on and switch to the OSS shell by typing OSH at the TACL prompt: >OSH 2. Change directories to the nonsecure DNS directory: $ cd /etc/dns_secure/ Note. In this manual, the dollar sign ($) indicates the OSS shell prompt. 3. Start named by typing the following command: $ named -c /etc/dns_secure/named.conf 4. To check that the named process is running, type: $ ps more Stop DNS The DNS (named process) can be stopped two ways: By using the tool rndc (see rndc on page 2-7) By using the OSS kill command Signals such as SIGINT and SIGTERM can be passed to the named process by using the kill command; the kill command stops the named process. 1. To obtain the process ID for the named process, type the following command: $ ps more 2. To stop named, type the following command: $ kill -term process-id The kill command sends the SIGTERM signal to the named process, causing the process to terminate. Note. If named is a persistent process, see Managing Persistence for the named Process on page 3-22; the kill command does not stop a persistent named process. 1-3

24 Quick Start Stop DNS 1-4

25 2 BIND 9.x on the NonStop Server This section provides information about the implementation of BIND 9.x on the NonStop Server, including: DNS and BIND 9.x on the NonStop Server on page 2-1 DNS Tools and Utilities on page 2-4 Application Programmatic Interface (API) for DNS on page 2-17 DNS and BIND 9.x on the NonStop Server This subsection provides information about DNS and BIND 9.x on the NonStop, including: Product IDs on page 2-1 Features on page 2-1 System Requirements on page 2-2 Restrictions on page 2-2 Assumptions and Dependencies on page 2-2 Running DNS in the Open System Services (OSS) Environment on page 2-2 Product IDs The product number for nonsecure DNS is T0685. The product number for secure DNS is T0708. Features Nonsecure DNS is based on BIND and provides the following features not available in DNS 4.8: Support for Incremental Zone Transfer (IXFR), Notify, and Dynamic Updates. Support for IPv6 address resolution using A6 Resource Records (RRs), DNAME RRs, and bitstring labels Support for binding a name with the user-specified TCP/IP process during run time Support for allowing applications to choose a resolver configuration file other than default /etc/resolv.conf file Support for all features available in the older DNS without regression 2-1

26 BIND 9.x on the NonStop Server System Requirements Secure DNS is based on BIND 9.3 and provides all the features of nonsecure DNS and the following additional features: Secret Key Transaction Authentication Transaction Signatures for DNS (TSIG) DNS security and related tools System Requirements Hardware Software Restrictions To make DNS a persistent process using the NonStop Kernel Persistence Manager ($ZZKRN), you should have the G06.24 or later RVU installed on the system. The -n parameter for threading is only supported for single threading; any nonzero specification for this parameter to the named run command is ignored. Assumptions and Dependencies Applications running in either OSS or Guardian can access the name but the named process must run in OSS. For the name to listen on IPv6 addresses, NonStop TCP/IPv6 must be running in DUAL or INET6 mode. (Refer to the TCP/IPv6 Configuration and Management Manual in NTL.) $ZZKRN is used to make DNS run as a persistent process. Running DNS in the Open System Services (OSS) Environment DNS is provided in the OSS environment but the application programmatic interface (API) works in both the OSS and Guardian sockets library environments. The man pages and files are all on the OSS operating system but you can start some processes and view files from the Guardian environment as well. The Open System Services User s Guide provides information about interoperating between the Guardian and OSS environments. This subsection provides information about: Locating DNS man Pages in OSS on page 2-3 Locating DNS Files in OSS on page 2-4 HP NonStop S-series or HP Integrity NonStop NS-series Open System Services (OSS) 2-2

27 BIND 9.x on the NonStop Server Running DNS in the Open System Services (OSS) Environment Locating DNS man Pages in OSS Nonsecure DNS (product ID T0685) is located in OSS in the /etc/923/ directory and secure DNS (product ID T0708) is located in /etc/dns_secure/. The default location of man pages in the OSS environment is /usr/share/man. Table 2-1. OSS Commands to Access man Pages Topic dig utility dnssec-keygen utility dnssec-signzone utility gethostbyname2 library call lwresd (lightweight resolver demon) lwres_freeaddrinfo library call lwres_freehostent library call lwres_gai_strerror library call lwres_getaddrinfo library call lwres_gethostbyaddr library call lwres_gethostbyname library call lwres_gethostbyname2 library call lwres_getipnodebyaddr library call lwres_getipnodebyname library call lwres_getnameinfo library call lwres_hstrerror library call named process (nonsecure) named process (secure) named.conf file nsupdate utility (secure) nsupdate utility (nonsecure) resolv.conf file rndc utility (secure) rndc utility (nonsecure) OSS Command to Access man Page man dig man dnssec-keygen man dnssec-signzone man gethostbyname2 man lwresd man lwres_freeaddrinfo man lwres_freehostent man lwres_gai_strerror man lwres_getaddrinfo man lwres_gethostbyaddr man lwres_gethosbyname man lwres_gethosbyname2 man lwres_getipnodebyaddr man lwres_getipnodebyname man lwres_getnameinfo man lwres_hsterror man named man dnssec_named man named.conf man dnssec_nsupdate man nsupdate man resolv.conf man dnssec_rndc man rndc 2-3

28 BIND 9.x on the NonStop Server DNS Tools and Utilities Locating DNS Files in OSS Table 2-2. Files for Nonsecure and Secure DNS Products Nonsecure DNS Files Located in /etc/dns923/ named lwresd named-bootconf.sh dig nsupdate rndc db.cache db.myzone.com.in named.conf rndc.conf Secure DNS Files Located in /etc/dns_secure/ named lwresd named-bootconf.sh dig nsupdate rndc db.cache db.myzone.com.in named.conf rndc.conf dnssec-keygen dnssec-signzone DNS Tools and Utilities DNS on the NonStop supports these tools, which are described in this subsection: Dynamic Update on page 2-4 rndc on page 2-7 Incremental Zone Transfer (IXFR) on page 2-9 dig on page 2-11 named-bootconf on page 2-12 nsupdate on page 2-12 DNS Security Extensions (DNSSEC) Tools on page 2-13 IPv6 Address Support on page 2-14 Dynamic Update Dynamic DNS update is the ability to add, modify, or delete resource records in the master zone files under a specified zone automatically, without editing the zone file. Dynamic update is based on RFC 2136 Dynamic Updates in the Domain Name System (DNS Update). You can use the utility nsupdate on page 2-12 to submit dynamic DNS update requests to a name. 2-4

29 BIND 9.x on the NonStop Server Dynamic Update For dynamic updates to be processed by the name, you must specify the IP addresses of the systems from where the requests can be received in the configuration file under the zone entry. Note. In this manual, configuration file and named.conf file are used interchangeably. You can enable dynamic update on a zone-by-zone basis by including an allow-update or update-policy clause in the zone statement. The basic syntax of such an entry in the configuration file is: zone "zone-name" { type master; file "zone filename"; allow-update { list of IP-addresses; }; }; All changes made to a zone using dynamic update are stored in the zone s journal file. This file is automatically created by the when the first dynamic update takes place. To form the name of the journal file, append the extension.jnl to the name of the corresponding zone file. The journal file is in a binary format; do not edit this file manually. Key Aspects of the Dynamic Update Process Note. The client is the host initiating the dynamic update; in the DHCP example that follows, the client is the DHCP. The client queries its configured name to find the authoritative name for the domain name it is attempting to update. The local name for the client performs the standard name-resolution process to discover the authoritative name. The client sends a dynamic update request to the authoritative name for the zone that the client is attempting to update. The dynamic update request of the client may include a list of prerequisites that must be fulfilled before an update can be made. During processing, the name changes the zone and increments the serial number (resource record parameter) to signal the change to the zone s slave. Slave s get a new copy of the zone through zone transfers or Incremental Zone Transfers. The List of Prerequisites When an authoritative DNS receives a dynamic update request, it checks whether prerequisites have been fulfilled. If the prerequisites are fulfilled, it performs the requested update. In our example, the DNS s client is the DHCP. The 2-5

30 BIND 9.x on the NonStop Server Dynamic Update DHCP must have dynamic update capability; however, the DHCP and the DNS need not reside on the same subnetwork. The prerequisites may be of the type: The resource record set exists The resource record set does not exist The name is in use The name is not in use Tracking the Update Versions One of the parameters of the Start of Authority (SOA) resource record is the serial number, which identifies the version of the zone information. Once an update is done, the master increments the serial number and sends out a Notify announcement with the serial number to the zone s slaves. This Notify message is sent only to the set of machines whose IP addresses have been specified in the also-notify option statement in the configuration file. The secondary s now get a copy of the updated zone file through zone transfers or Incremental Zone Transfers. Note. It is very important that secret slave s, which the master is unaware of, are listed in the also-notify zone option in the master s named.conf file. This arrangement is only necessary if you have secret slaves for which NS records are not kept in the master 's zone data file because no other mechanism exists through which the master would know who its secret slave s are. Note. You can use the allow-update option to specify which hosts are allowed to submit dynamic DNS updates for master zones. By default, updates from all hosts are denied. The allow-update option is not applicable for slave zones. You can configure slave s to forward any dynamic updates to their zone data to the master for the zone by adding the allow-update-forwarding option to the slave zone statement in the named.conf file. The allow-update-forwarding option takes an ACL as its parameter. (See Use ACLs on page 3-9.) Example 2-1. Zone File With allow-update zone "example.com " { type master; file "db.example"; allow-update { ; }; }; 2-6

31 BIND 9.x on the NonStop Server rndc rndc This example indicates that the name is a master for the zone example.com and the name can update the zone data file db.example upon receiving the update requests from the system configured with IP address The allow-update clause specifies which hosts are allowed to submit dynamic DNS updates for master zones. The default is to deny updates from all hosts. For more information about the nsupdate utility, see the man page and nsupdate on page (See Table 2-1, OSS Commands to Access man Pages, on page 2-3 for information about accessing the man pages in OSS.) The Remote Name Demon Control (rndc) utility enables you to control the operation of a name. Note. In this manual and in the OSS documentation demon is used instead of daemon. The rndc utility has the following syntax: rndc [-c config file] [-s ] [-p port] [-y key] command [command...] -c config file Specifies an alternate configuration file. The default configuration file is /etc/rndc.conf. -s Specifies the whose operation needs to be controlled. -p port Instructs rndc to send commands to the port number specified port on the system running the name instead of to BIND s default control-channel port number y key Identifies the key ID from the configuration file. Table 2-3. rndc Commands (page 1 of 2) Command reload reload zone [class [view]] refresh zone [class [view]] Description Reload configuration file and zones. Reload the given zone. Schedule maintenance for the given zone. 2-7

32 BIND 9.x on the NonStop Server rndc Table 2-3. rndc Commands (page 2 of 2) Command Description stats Write statistics to the statistics file. querylog Toggle query logging. dumpdb Dump the current contents of the cache into the file specified by the dump-file option in the named.conf file. stop Stop the after saving recent changes to the master files of the updated zones. halt Stop the immediately without saving recent changes to the master files. reconfig Reload only the configuration file and new zones. trace Increment the debugging level by 1. notrace Set the debugging level to 0. trace level Change the debugging level. flush Flush all the s caches. flush [view] Flush the s cache for a particular view. status Display the status of the. Example: Generating the rndc.conf File and Running rndc 1. Assume that the configuration file /etc/dns_secure/named.conf has a key statement for rndckey similar to: controls { inet allow { ; } keys { rndckey;}; }; 2. Create the configuration file rndc.conf as an ASCII file: key rndckey { algorithm "hmac-md5"; secret "IbtRYdcP8k2mVtel6aYfbQ=="; }; options { default- localhost; default-key rndckey; }; 2-8

33 BIND 9.x on the NonStop Server Incremental Zone Transfer (IXFR) 3. Run the rndc command: $ rndc -c /etc/dns_secure/rndc.conf reload This command results in a connection to the port 953 and reloads the name. Example: Using rndc to Stop the Name Server In the following example, rndc stops the name running on Example 2-2. rndc Command > rndc -c /etc/dns_secure/rndc.conf -s stop The communication between the name and rndc is secured by a shared secret key. rndc reads the rndc configuration file to determine how to contact the name and decide what algorithm and key to use. For more information, see the rndc man pages in OSS. (For help locating the man page, see Table 2-1, OSS Commands to Access man Pages, on page 2-3.) Incremental Zone Transfer (IXFR) Incremental zone transfer is a mechanism for slave s to transfer only the changed data instead of transferring the entire zone data every time the zone data changes. RFC 1995, Incremental Zone Transfer in DNS introduced Incremental Zone Transfers (IXFR) describes this tool. IXFR is set to ON by default. Note. IXFR works best if you use dynamic updates to modify your zone files. Slave s inform master s about the version of a zone they currently hold and request just the changes to the zone between the version they have and the current version. This arrangement dramatically reduces the size and duration of a zone transfer. Transferring very large zone files can take a long time and waste bandwidth and other resources, especially if only a single record has been changed. An incremental zone-transfer request has a query type of IXFR instead of AXFR (the type of query that initiates a full zone transfer), and it contains the slave's current start of authority (SOA) record from the zone in the authority section of the message. Incremental zone transfers are always carried out using TCP on port 53 not UDP. (Normal DNS query operations use UDP on port 53.) When the master name receives an incremental zone-transfer request, it looks for the record of the changes to the zone between the slave's version of the zone and the version the master holds. If that record is missing, the master sends a full zone transfer. Otherwise, it sends just the differences between the versions of the zone. When acting as a slave, BIND attempts to use IXFR unless incremental zone transfer is explicitly disabled. 2-9

34 BIND 9.x on the NonStop Server Incremental Zone Transfer (IXFR) The statements used to enable and disable the IXFR feature for the master are: [Provide-ixfr yes_or_no;] [Request-ixfr yes_or_no;] The syntax for setting the statement in the configuration file for the master is: Server ip-address { }; provide-ixfr no[yes]; Example 2-3. Setting the Server Statement to Disable IXFR Server { provide-ixfr no; }; The IP address specified causes the local, acting as the master, not to provide IXFR to the remote slave The syntax for setting the statement in the configuration file for the local slave is: Server ip-address { }; request-ixfr no[yes]; Example 2-4. Setting the Server Statement in the Configuration File Server { request-ixfr no; }; The IP address specified causes the local, acting as a slave, not to request IXFR from the remote master

35 BIND 9.x on the NonStop Server dig Remember, the default for both the master and slave for IXFR is yes. Note. A BIND master name that reloads an entire zone data file cannot compute the differences between that zone and the previous zone. Nor can a BIND slave that gets a full zone transfer figure out what changed between the new zone and the previous zone. Therefore, to take full advantage of IXFR, you should modify your zone only by using dynamic update and never edit the zone data file manually. dig dig is a command line tool used to gather information from the DNS s. dig operates in two modes: Simple interactive mode for a single query Batch mode, which runs a query for each item in a list of several query lines The syntax for DIG is: dig [@] [options] domain [query-type] [query-class] [query-options] See the dig man page for the description of the options for the dig command. (See Table 2-1, OSS Commands to Access man Pages, on page 2-3 for information about accessing the man pages.) Examples: Using dig Example 2-5. Using dig $ fakir dns3.brazil.hp.com A IN Note. You must always use fully qualified domain names as arguments to dig. Example 2-6. Obtain the Latest List of Root Domain Servers $ dig. ns Example 2-7. Find the Name Servers for a Zone $ domain ns Example 2-8. Request all Records for a Zone From an Authoritative Server $ domain axfr Note. This command requires a zone transfer, which the may disallow. 2-11

36 BIND 9.x on the NonStop Server named-bootconf Example 2-9. Look Up the Domain Name Corresponding to an IP Address $ dig -x Refer to the dig man page for more information about the output format. named-bootconf The named-bootconf tool is a shell script that converts a DNS configuration file to a DNS 9.x configuration file. The syntax for this tool is: $named-bootconf.sh < DNS configuration file (input) > DNS 9.x configuration file (output) Note. < and > are redirection operators. The DNS configuration-file syntax has changed significantly from Version 4.x to Version 9.x. The DNS 4. configuration file can be converted to a DNS 9.x configuration file by running the script named-bootconf.sh. This shell script takes the old configuration file as input and produces the new syntax as output, which can then be redirected to a file. In the following example, the name of the old configuration file (DNS 4.x format) is named.boot, and the name of the new generated file (DNS 9.x format) is named.conf. Example Migrating the Configuration File $named-bootconf.sh < named.boot > named.conf Note. Since the manner of specifying pathnames is different in Guardian and OSS, you must ensure that the new configuration file (after conversion) contains the appropriate path of the zone files. nsupdate The nsupdate tool updates DNS domain name s that support dynamic updates (option allow-update yes). nsupdate uses the DNS resolver library to pass messages to a name, requesting the insertion or deletion of DNS RRs. The syntax for this tool is: $nsupdate [-k keydir:keyname] [-d] [-v] [filename] where: 2-12

37 BIND 9.x on the NonStop Server DNS Security Extensions (DNSSEC) Tools -k option sign updates with TSIG -d sets the debug mode -v tells nsupdate to use TCP/IP to communicate with the Example: Running nsupdate The following example illustrates the interactive use of nsupdate. In this example, nsupdate connects to a name running on Then the existing record old.example.com is deleted, and a new record new.example.com is added. Example Using the nsupdate Tool $nsupdate > >update delete old.example.com A >update add new.example.com 3600 A > >quit DNS Security Extensions (DNSSEC) Tools DNSSEC provides the following tools. (For more information about these tools, see the OSS man pages; also see Table 2-1, OSS Commands to Access man Pages, on page 2-3 for guidelines for locating the man pages.) dnssec-keygen DNSSEC Key Generation Tool dnssec-keygen generates a key pair which can be used for TSIG or DNSSEC and generates two output files:.private file and.key file. The private key (in the.private file) is used to generate signatures, and the public key (in the.key file) is used for signature verification. Example dnssec-keygen $ dnssec-keygen -a RSA -b 512 -n ZONE example.com. The -a option specifies the cryptographic algorithm to use (RSA in this case). The option -b is the length of the keys to generate, in bits. RSA keys can be from 512 to 2,000 bits long. The option -n specifies the type of key. DNSSEC keys are always zone keys. The only argument that is not an option is the domain name of the zone to be signed, which is example.com in this case. 2-13

38 BIND 9.x on the NonStop Server IPv6 Address Support dnssec-keygen prints the basename of the files to which it writes the generated keys on the terminal. The public key is written to the file basename.key. The private key is written to the file basename.private. dnssec-signzone DNSSEC zone signing tool dnssec-signzone signs a zone file. It generates NSEC and RRSIG records and produces a signed version of the zone file. If the zone s parent produces a signed-key file (output of dnssec-signkey), the parent's signatures are incorporated into the generated signed zone file. The security status of delegations from the signed zone (that is, whether the child zones are secure) is determined by the presence or absence of a signed key file for each child zone. Example dnssec-signzone $> dnssec-signzone -o example.com. db.myzone.com.in The -o option specifies the origin in the zone data file. The last argument is the zone file name which is db.myzone.com.in in this case. The output would be a signed zone file named db.myzone.com.in.signed. For more information about the syntax and use of DNSSEC tools, refer to the OSS man pages. (See Table 2-1, OSS Commands to Access man Pages, on page 2-3 for guidance in accessing the man pages.) IPv6 Address Support Current support for the storage of Internet addresses in the Domain Name System is not easily extended to support IPv6 addresses since most applications still assume that address queries return 32-bit IPv4 addresses only. To support the storage of IPv6 addresses, several new resource record types are defined. A new domain is defined to support lookups based on address. 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 changes are designed to be compatible with existing software. The existing support for IPv4 addresses is retained. Configuring named to support IPv6 By default, a BIND 9.x name does not listen for IPv6 based queries. To configure it to listen on the local host's IPv6 network interfaces, use the listen-onv6 option in the configuration file. 2-14

39 BIND 9.x on the NonStop Server IPv6 Address Support Example Setting named to Listen on IPv6 Interfaces options { listen-on-v6 { any; }; }; The listen-on-v6 option accepts only any and none as arguments. BIND 9.x lets you determine which IPv6 address to use in Notify messages, by using the notify-source option statement. The IPv6 option statement is called notifysource-v6. Example Setting the IPv6 Address for Notify Messages options { notify-source-v6 }; The A6 and DNAME Records IPv6 forward and reverse mapping uses two new record types: A6 and DNAME records described in RFC 2874, DNS Extensions to Support IPv6 Address Aggregation and Renumbering and RFC 2672, Non-Terminal DNS Name Redirection respectively. A6 records can specify only a part of an IPv6 address, such as the last 64 bits (the interface ID) assigned to a host's network interface, and refer to the remainder of the address by a symbolic domain name. This arrangement allows zone administrators to specify only the part of the address under their control. For example, consider the A6 record: 222:10:2521:1:210:4bff:fe10:d24; $ORIGIN hp.com inventor IN A6 64 ::0210:4bff:fe10:0d24 subnet1.v6.hp.com specifies the final 64 bits of the inventor.hp.com IPv6 address (64 is the number of bits of the prefix not specified in this A6 record) and that the remaining 64 bits can be found by looking up an A6 record at subnet1.v6.hp.com. subnet1.v6.hp.com, in turn, specifies the last 16 bits of the 64-bit prefix (the SLA ID) that not specified in inventor.hp.com's A6 address as well as the domain name of the next A6 record to look up: $ORIGIN v6.hp.com. subnet1 IN A6 48 0:0:0:1:: hp-res.lab1.net. subnet1 IN A6 48 0:0:0:1:: hp.lab2.net. 2-15

40 BIND 9.x on the NonStop Server IPv6 Address Support The first 48 bits of the prefix in subnet1.v6.hp.com's record-specific data are set to zero since they are not significant here. These records tell us to look up two A6 records next, one at hp-res.lab1.net and one at hp.lab2.net. By following a chain of A6 records, a name can assemble all 128 bits of the two inventor.hp.com IPv6 addresses. Note. If a name appears in a name (NS) record and owns one or more A6 records, those A6 records should specify all 128 bits of the IPv6 address. This arrangement helps avoid deadlock problems, where a resolver or name needs to talk to a remote name to resolve part of that name 's IPv6 address. Reverse mapping IPv6 addresses involves DNAME records, described in RFC 2672 Non-Terminal DNS Name Redirection and bitstring labels, introduced in RFC 2673 Binary Labels in the Domain Name System. DNAME records are like wildcard CNAME records. They substitute one suffix of a domain name with another. For example, if you had previously used the domain name hpedu.com at HP University but had since changed to hpuniv.com, you could have replaced the old hpedu.com zone with this one: $TTL IN SOA instructor.hpuniv.com root.hpuniv.com. ( h 30m 30d 1h ) IN IN NS instructor.hpuniv.com. NS developer.hpuniv.com. IN MX 10 dnscoursewbt.hpuniv.com. IN DNAME hpuniv.com. The DNAME record in the hpedu.com zone applies to any domain name that ends in hpedu.com except hpedu.com itself. Unlike the CNAME record, the DNAME record can coexist with other record types owned by the same domain name as long as the records are not CNAME or other DNAME records. However, the owner of the DNAME record may not have any subdomains. When the hpedu.com name receives a query for any domain name that ends in hpedu.com (for example, courses.hpedu.com) the DNAME record tells the 2-16

41 BIND 9.x on the NonStop Server Application Programmatic Interface (API) for DNS to synthesize an alias from courses.hpedu.com to courses.hpuniv.com, replacing hpedu.com with hpuniv.com: courses.hpedu.com. IN CNAME courses.hpuniv.com. The hpedu.com name replies with this CNAME record. If the hpedu.com name is responding to a newer name, it also sends the DNAME record in the response, and the recipient name can then synthesize its own CNAME records from the cached DNAME. Bitstring labels are another aspect of IPv6 reverse mapping. Bitstring labels are a compact way of representing a long sequence of binary (for example, one-bit) labels in a domain name. Bitstring labels concatenate the bits in successive labels into a shorter hexadecimal, octal, binary, or dotted-octet string. Together, DNAMEs and bitstring labels are used to match portions of a long domain name that encodes an IPv6 address and to iteratively change the domain name looked up to a domain name in a zone under the control of the organization that manages the host that has that IPv6 address. For more information about IPv6 forward and reverse mapping, see DNS and BIND 4th edition by Paul Albitz and Cricket Liu. Application Programmatic Interface (API) for DNS Resolvers are typically perceived to be the clients that access name s. However, it is better to think of the resolver as a set of procedures that are called by any process that needs to ask questions of a DNS. Each time a service is invoked, such as Telnet or FTP, specifying a target hostname, the service indirectly launches a resolver routine (library call) such as gethostbyname(). Since the networking software uses IP addresses rather than names, the host name must be resolved or mapped to an IP address; gethostbyname() resolves the name to the IP address by using DNS (or a hosts file if the system is configured to use a hosts file instead of DNS). In addition to the standard API that comprises the resolver, BIND 9 provides an alternative lightweight resolver library for local clients and a lightweight demon process for fast, more efficient address resolution. For more information about the lightweight resolver, see Using the Lightweight Resolver on page 3-1 and Lightweight Resolver Library and Demon on page A-4. A different API exists for the lightweight resolver library that provides library calls based on the same functionality and syntax as the API for the traditional socket library. Applications running on Guardian or OSS can make use of these APIs, which include: lwres_gethosbyname lwres_gethostbyname2 lwres_gethostbyaddr lwres_getaddrinfo lwres_freeaddrinfo 2-17

42 BIND 9.x on the NonStop Server Application Programmatic Interface (API) for DNS lwres_gai_strerror lwres_getnameinfo lwres_getipnodebyname lwres_getipnodebyaddr lwres_freehostent lwres_hstrerror For information about these library calls as well as the standard ones, see the OSS man pages or the TCP/IP Programming Manual. 2-18

43 3 DNS Configuration on the NonStop Server This section provides background information, procedures, and examples for configuring the lightweight resolver, security and other tasks specific to NonStop systems. Topics in this section include: Starting the named Demon on page 3-1 Using the Lightweight Resolver on page 3-1 Understanding DNS Security Threats on page 3-3 Implementing DNS Security Solutions on page 3-8 Managing Persistence for the named Process on page 3-22 Specifying a TCP/IP Process by Using a Runtime Option on page 3-23 Specifying a Different resolv.conf File on page 3-23 Specifying Multiple Names in the Resolver by Using Sections on page 3-24 Tips and Important Tasks on page 3-26 Starting the named Demon The syntax for the named command is: named [-4] [-6] [-c config-file] [-d debug-level] [-f] [-g] [-p port] [-s] [-t directory] [-T tcpip-process-name] [-u ] [-v] [-x cache-file] For information about the parameters to the named command, see the man pages in OSS. (See Table 2-1, OSS Commands to Access man Pages, on page 2-3.) Example 3-1. Starting named $ named -g -c /etc/dns_secure/named.conf Using the Lightweight Resolver IPv6 introduces a new complexity into the host name resolution process, such as following A6 chains and DNAME records and simultaneous lookup of IPv4 and IPv6 addresses. These features are difficult to implement in a traditional stub resolver. Instead, BIND 9 (and higher) provides resolution services to local clients using a combination of a lightweight resolver library and lightweight resolver demon process 3-1

44 DNS Configuration on the NonStop Server Lightweight Resolver demon running on the local host. Since the lightweight demon runs on every host and regularly caches DNS data, the network communication is greatly reduced and results in improved performance. Lightweight Resolver demon The lightweight demon (lwresd) runs only in the OSS environment. It listens for resolver queries on a UDP port on the IPv4 loopback interface, , or the IPv6 loopback interface ::1. lwresd can only be used by processes running on the local machine. By default, port number 921 is used for lightweight resolver requests and responses. Incoming lightweight resolver requests are decoded by the name, which then resolves them using the DNS protocol. When the DNS lookup completes, lwresd encodes the answers in the lightweight resolver format and returns them to the client that made the request. If the /etc/resolv.conf file contains any name entries, lwresd sends recursive DNS queries to those s. This is similar to the use of forwarders in a caching name. If no name entries are present or if forwarding fails, lwresd resolves the queries autonomously starting at the root name s, using a built-in list of root hints. The simplest way of starting the lwresd process is to run it with the default options. The IP addresses of the name s to contact will be read from the /etc/resolv.conf file. For example: $> lwresd Compiling Existing DNS Applications to Use the Lightweight Resolver Library You can recompile applications that use the native, socket-library-resolver APIs to use the lightweight-resolver APIs without making changes to the source code. To change your applications to use the lightweight resolver APIs, recompile the application with the -DLWRES compiler option. This option instructs the preprocessor to make the following replacements in the application program: gethostbyname gethostbyname2 gethostbyaddr getnameinfo getaddrinfo freeaddrinfo is replaced by lwres_gethostbyname is replaced by lwres_gethostbyname2 is replaced by lwres_gethostbyaddr is replaced by lwres_getnameinfo is replaced by lwres_getaddrinfo is replaced by lwres_freeaddrinfo gai_strerror is replaced by lwres_gai_strerror hstrerror is replaced by lwres_hstrerror 3-2

45 DNS Configuration on the NonStop Server Understanding DNS Security Threats h_errno is replaced by lwres_h_errno getipnodebyname getipnodebyaddr freehostent is replaced by lwres_getipnodebyname is replaced by lwres_getipnodebyaddr is replaced by lwres_freehostent Understanding DNS Security Threats Different levels of security exist for your DNS implementation on the NonStop depending on whether you are using DNS s for local address resolution or using them in the broader domain name system on the Internet. Planning for DNS security involves understanding the nature of security threats in the DNS environment and the tools and techniques for mitigating those threats. To assess the potential threats and the possible counter-measures in a DNS network, you must first understand the normal data flows in a DNS system and the areas that are potential sources of threat. You must determine what areas you want to secure and the threat level you want to secure against. The first step in a good security plan is to audit what threats are applicable and determine how seriously you rate these threats. For example, if you do not do dynamic updates, there is no dynamic update threat. Note. The further you go from the master, the more complicated the security solution and the implementation. For this reason, you should start from the master and work outward. The classification of threats in this subsection helps in selecting appropriate remedies and strategies for avoiding threats or securing the system. Table 3-1. DNS Security Threats Area Zone files Zone Transfers Dynamic updates Remote queries Resolver queries Threat File corruption (malicious or accidental). This is a local threat. IP address spoofing (impersonating update source). This is a -to- threat. Unauthorized updates, IP address spoofing (impersonating update source). This is a -to- threat. Cache poisoning by IP spoofing, data interception, or a subverted master or slave. This is a -to-client threat. Data interception, poisoned cache, subverted master or slave, local IP spoofing. This is a remote client-to-client threat. 3-3

46 DNS Configuration on the NonStop Server Local Threats Local Threats The primary source of zone data is normally the zone files, as well as the named.conf file, which contains sensitive data as well. This data should be secure and securely backed up. This threat is classified as local and is typically handled by good system administration. Figure 3-1. Local File Update Threat From File Corruption Zone files Possible Security Threats master master DHCP zone files slave slave vst009.vsd 3-4

47 DNS Configuration on the NonStop Server Zone Transfer Threat Zone Transfer Threat If you run slave s you will do zone transfers, which introduce a potential to- threat. Figure 3-2. Zone Transfer Threat, IP Address Spoofing Possible Security Threats DHCP Client Zone transfers master master remote caching zone files slave slave Client vst005.vsd 3-5

48 DNS Configuration on the NonStop Server Dynamic Update Threat Dynamic Update Threat The BIND default is to deny dynamic zone updates. If you have enabled this service, it may pose a threat to the integrity of your zone files and may need to be protected. Dynamic zone updates are also classified as a -to- threat. Note. The BIND Administrator Reference Manual suggests multiple techniques for protecting against dynamic update threats, including using the update-policy option instead of allow-update or specifying only TSIG key names, not IP addresses, when using allowupdate. Figure 3-3. Dynamic Update Threat Possible Security Threats Dynamic updates DHCP Client master master remote caching Client zone files slave slave vst007.vsd 3-6

49 DNS Configuration on the NonStop Server Remote Query Threat Remote Query Threat There is a possibility of remote cache poisoning due to IP spoofing or data interception and other hacks if you are running a simple web site. Remote cache poisoning is classified as a -to-client threat. Figure 3-4. Remote Query Threat, Server to Client Possible Security Threats DHCP Client master master Remote queries remote caching Client zone files slave slave vst008.vsd 3-7

50 DNS Configuration on the NonStop Server Remote Caching Corruption Threat Remote Caching Corruption Threat At this time, securing resolvers is not standardized. Resolver queries are classified as a client-to-client threat. Figure 3-5. Remote Caching Corruption Threat, Client to Client Possible Security Threats DHCP Client master master remote caching Resolver Queries zone files slave slave Client vst006.vsd Implementing DNS Security Solutions You can use several tools and techniques exist to control the possible security threats in your DNS architecture. For simplicity in providing examples, this subsection assumes that you are either running DNS on your NonStop internally and need just basic security or that you are connecting the NonStop to the Internet and need maximal security. Some methods apply to both scenarios. Note. RFC 3833, Threat Analysis of the Domain Name System (DNS), provides an important analysis of security threats and the limitations to DNSSEC. 3-8

51 DNS Configuration on the NonStop Server Use ACLs Table 3-2. Possible Solutions for DNS Security Threats* Administrative Type of Threat ACLs help? Techniques help? TSIG helps? DNSSEC helps? Denial of Service No No No No Name Chaining No No Yes Yes Attacks Cache Poisoning Yes No No No Glue records No No No Partially Dynamic update No No Yes Yes Data corruption No Yes No No * Source: RFC 3833 Threat Analysis of the Domain Name System Assuming that you want to use DNS internally, you can apply a combination of the following tools to secure the environment. (All of these tools are available in the nonsecure DNS product on the NonStop system, in the /etc/dns923/ OSS directory.) Use ACLs on page 3-9 Conceal the BIND Version on page 3-15 Protect the Configuration File: Restrict the Privilege of named and Run It in a chroot-jail on page 3-15 Use TSIG on page 3-16 Configure Views on page 3-18 Use Firewalls and a Bastion Host on page 3-19 Use Public Key Cryptography: DNSSEC on page 3-20 Assuming that you want to connect your DNS environment to the Internet, HP strongly recommends that you apply a robust security configuration and consider using a combination of the preceding tools. In addition, HP recommends reading all pertinent RFCs and DNS and BIND 4th edition by Paul Albitz and Cricket Liu. Use ACLs By using access control lists, you can help address the security risks involved in queries, zone transfers, and updates. (For information about these threats, see Zone Transfer Threat on page 3-5, Dynamic Update Threat on page 3-6, and Remote Query Threat on page 3-7.) ACLs rely on trust relationships between s and clients. An ACL restricts access to DNS information according to IP addresses. These restrictions are still vulnerable to IP address spoofing (attacking nodes that assume the IP address of a trusted node). ACL transactions include: 3-9

52 DNS Configuration on the NonStop Server Use ACLs Queries By default, a DNS answers recursive queries from any node. In some cases, this arrangement may expose the name to denial-of-service attacks from the Internet, where a malicious user floods the name with recursive queries. Zone Transfers By default, a DNS sends the contents of its zone databases to any node that requests this content. In some cases, attackers can use this information to determine your infrastructure or the addresses of routers and other machines vulnerable to attack. To avoid this problem, you can restrict zone transfers to the other s in the zone. Although IP-based ACLs are relatively easy to subvert, they are much better than nothing and require very little work. If you were to run with multiple masters and no slaves, you would eliminate the threat entirely. Updates By default, a DNS does not accept any requests to update its resource records. However, you may want a DNS to accept updates from specific systems, such as DHCP s. If you are using Dynamic DNS, the DHCP sends update requests to the DNS that map the client host names to dynamically assigned IP addresses. See Dynamic Update on page

53 DNS Configuration on the NonStop Server Use ACLs Use ACLs to Restrict Recursion Figure 3-6 shows how a corporation like HP might use BIND security options to connect to the Internet. Figure 3-6. ACL Example: Internet Internet HP internal Firewall HP external HP-internal roots! internal hp.com root s (update manage db.hp, db.15; an SOA for DP.HP, DB.15)! forward queries about outside world to HP external s! allow-query {hp_hosts;}; allow-transfer {hp_s;}; HP-external s! only allow port 53 traffic! selected RRs for hp.com! delegated by INTERNIC root, COM, as s for hp.com, 15.inaddr.arpa! allow-query (any;);! allow-transfer {none; }; vst026.vsd By default, a DNS answers queries from any client resolver. Queries received from client resolvers are typically recursive; that is, the client resolver asks the DNS to find the answer on the client's behalf. Finding the answer requires the DNS to send queries to several other name s. (See Name Servers: Recursive and Nonrecursive Resolution on page A-8.) This process of request and referral puts a heavy load on your DNS s named process and could expose the name to a denial-of-service attack from the Internet whereby a malicious user floods the name with recursive queries. 3-11

54 DNS Configuration on the NonStop Server Use ACLs To avoid your name being flooded with inappropriate recursive queries, you can restrict the name not to accept recursive queries at all or only to accept recursive queries from certain clients. (This restriction might be sensible for a secondlevel name which does not appear in the /etc/resolv.conf file of any resolving clients.) Use the option allow-recursion to restrict recursive queries. To restrict your name from accepting any queries at all, which you might want to do in a firewalled internal and external environment as shown in Figure 3-6, except from certain sources, use the option allow-query to restrict all types of query. (Configure allow-query in named.conf.) The HP external s in the diagram provide a selective view of the HP domain to the outside world and resolve HP client requests about the outside world. The external s might be connected directly to the Internet or behind the firewall. Traffic could be restricted to DNS (UDP and TCP port 53). The s could have just a subset of resource records for the hp.com domain, such as resource records for mail hubs and selected http s. The HP external s would be delegated by the INTERNIC address (inaddr.arpa) and the hp.com domain. This delegation causes queries about hp.com from outside HP to be sent to the HP external s. To configure ACL security, define ACLs in the named.conf file. The ACLs must be configured before they are used, so ACL statements are typically placed at the top of named.conf files. Example 3-2. Configuring ACL Security (named.conf) # Define ACL acl "name" { [:] addr[\num_mask_bits];... }; acl "dns-s" { ; ; acl "blue-net" { ]21; }; acl "no-badguy" {! ; ; }; An ACL definition can include multiple address specifications. Instead of using subnet masks to specify subnet address ranges, an address specification can include a suffix indicating the number of significant bits. The address specification for blue-net { \21;}; would be equivalent to specifying a subnet address using the address and the mask An exclamation point (!) excludes the address specification that follows it. 3-12

55 DNS Configuration on the NonStop Server Use ACLs You can use four predefined ACLs alone or with address specifications: any none localhost localnets When an ACL definition contains multiple elements, the elements are evaluated from left to right. The ACL "no-badguy" allows all addresses on the network except When specified with the allow-query option, the accepts all query requests from nodes on the network except Allow Directives allows all hosts denies all hosts Once you have defined the ACLs, you can use them in allow directives within zone statements. You can also specify the allow-query and allow-transfer directives in an options statement. An options statement defines global behavior for a, so any allow directives in an options statement apply to all the 's domains. Other Configuration Options allows the IP addresses of all interfaces on the system allows any host on a network for which the system has an interface Caution. If the ACL "no-badguy" had instead been specified as: acl "no-badguy" { ;! ; }; The ACL would allow all addresses on the network, including , since would first be checked against the specification and match. Note. The default for allow-updates is none. (The DNS does not accept any dynamic update messages.) The allow-updates statement is typically used to enable dynamic updates. ACLs have uses other than controlling access. You can think of ACLs as shortcuts to specifying an extended list or range of IP addresses for use in all sorts of different circumstances. You can use an ACL whenever the parameter address_match_list appears in the named.conf configuration file syntax. Examples of this usage include the sortlist and the listen-on option sub-statements. 3-13

56 DNS Configuration on the NonStop Server Use ACLs Figure 3-7. ACL Example: Restricting Zone Transfers master slave slave /etc/named.conf acl "DNS-SERVERS" { zone "animals.hp.com: { type master; file "db.animals:; allow-transfer {dns-s; }; zone " in-addr.arpa" { type master; file "db ";}; allow-transfer {dns-s; }; vst0025.vsd In Figure 3-7, the named.conf file is shown from the master. Only the other s for the animals.hp.com domain and the corresponding address domain ( in-addr.arpa) are allowed to receive zone transfers. You would put the same allow-transfer option statement in the zone statements on the slave s. Since the master only serves the animals.hp.com and in-addr.arpa and the list is the same for both domains, you could specify the allow- 3-14

57 DNS Configuration on the NonStop Server Conceal the BIND Version transfer directive once in the options statement instead of repeating it for each zone: options { allow-transfer { dns-s; }; }; Note. This solution is not completely secure because a rogue system could spoof one of the slave s and obtain a zone update by using the slave 's IP address. Conceal the BIND Version By default, your name returns its BIND version information to version.bind queries. Knowing which version of BIND you are running can enable a hacker to tailor attacks to your system, so HP recommends that you use the options version sub statement to override the version information with an alternate phrase as shown: options { version Restricted ; } To configure your name either not to return anything when queried for its version, or to provide version information to authorized requestors, see the DNS and BIND 4th edition by Paul Albitz and Cricket Liu which provides information about this more complex procedure. Protect the Configuration File: Restrict the Privilege of named and Run It in a chroot-jail As noted previously, the named.conf file can contain interesting data to an intruder. The named demon usually runs with privileged access, which increases the security risk if any vulnerabilities are found. To decrease this risk run named as a nonprivileged user and put its files in a restricted file system called a chroot-jail. A chroot-jail contains any intrusions. A successful attack on named in a chroot jail running as a nonprivileged user allows the attacker to modify only files owned or writeable by that nonprivileged user and protects the rest of the system. 3-15

58 DNS Configuration on the NonStop Server Use TSIG Use TSIG Figure 3-8. Updates Secured Through TSIG The name adds a TSIG record to the additional data section of a DNS message. DNS update message DHCP is nt4652 additional data TSIG Record DNS vst027.vsd TSIG provides secure -to- communication securing DNS messages by providing authentication and data integrity. TSIG secures -to- communication for 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 also used to authenticate control messages between rndc and named. When you configure TSIG, a name adds a TSIG record to the additional data section of a DNS message. The message can be verified by the receiver using the TSIG record 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. TSIG uses a one-way hash function to provide authentication and data integrity. A oneway hash function, or cryptographic checksum, computes a fixed-size hash value based on an arbitrarily large input. For a DNS message, the computation is done on the message itself (excluding the TSIG record). 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 the function cannot be reversed to recalculate the input that generated the output. The computed hash value is included in the TSIG record by the sender. The receiver of the message carries out the same computation as the sender (using the shared key) and compares the result with the hash value in the TSIG record. If the values are the same, the message is authenticated. Note. TSIG is used for the authentication of messages, not for encryption. Since the DNS message is not encrypted, it could be read in transit, but the TSIG record, along with the shared key held by sender and recipient, ensures that the message is transmitted intact. 3-16

59 DNS Configuration on the NonStop Server Use TSIG Steps to Configure TSIG for Securing Zone Updates: 1. Create the shared key using the dnssec-keygen tool. (See Generating a Key Pair on page 3-21.) 2. Share the generated key between the name s among which secure communication is desired. 3. Include the key in the key statement of the named.conf file of the primary name : Key key-name { algorithm hmac-md5; secret "generated-secret-key"; }; This example specifies a TSIG key for the name. The key directive specifies the algorithm to be used for verification and the generated key. To restrict zone transfers from a primary to slave s, use the allowtransfer directive in a zone definition: zone "example.com" { type master; file "db.example.com"; allow-transfer { key <key-name>; }; }; This example specifies that zone transfers for example.com would be sent only to those name s that have the specified key. 4. On the slave's end, configure the slave to sign zone transfer requests with the same key: Key key-name { algorithm hmac-md5; secret "generated-secret-key"; }; IP address of Primary { keys { key-name; }; The statement directs the slave name to sign all requests to the primary name using the specified key. 3-17

60 DNS Configuration on the NonStop Server Configure Views Configure Views Views allow you to present one name configuration to one set of hosts and a different configuration to another set. Whether you choose to use views depends on your overall architecture, firewall configuration, and security policy. You only need to configure and maintain a single named demon process instead of running multiple named processes on the same host (restricting each to a different network interface) or establishing completely separate name host machines, each serving a different community of hosts. When you set up views, there is a single interface box (sitting inside on the internal network or outside on the perimeter network) that distinguishes inside from outside by IP address. With two boxes, one inside and one outside, the firewall must distinguish inside from outside. In the following example, two views are available in the, one for internal clients using addresses and and the other for external clients that can be any address. For the internal clients, the local zone file is root.hint. For the zone example, the local zone file is internal.db. For the external clients, the local zone file is root.hint. For the zone example, it is example.db. 3-18

61 DNS Configuration on the NonStop Server Use Firewalls and a Bastion Host Example 3-3. Sample Configuration File for Views options { query-source address ; port 5300; pid-file named.pid ; listen-on { ;}; recursion no; notify yes; }; view internal [ match-clients { ; ;}; zone. { type hint; file root.hint ; }; zone example { type master; file internal.db ; allow-update {any;}; }; }; view external { match-clients {any;}; zone. { type hint; file root.hint ; }; zone example { type master; file example.db }; }; Use Firewalls and a Bastion Host On an HP NonStop system, if you are connecting to the Internet, you are probably using a firewall (which HP recommends). You can limit the internal hosts that can directly access the Internet because of the security risks inherent in allowing bidirectional DNS traffic through the firewall unrestricted. Several types of firewalls exist, the most common being packet filters and application gateways. In an application gateway firewall or for any firewall without the ability to pass DNS traffic, the only host 3-19

62 DNS Configuration on the NonStop Server Use Public Key Cryptography: DNSSEC that can communicate with Internet name s is called a bastion host, and all other name s communicate with the Internet through the bastion host. See DNS and BIND 4th edition by Paul Albitz and Cricket Liu 4th Edition for an in-depth discussion of using DNS with firewalls, forwarding, and forward zones. Use Public Key Cryptography: DNSSEC DNSSEC uses public key cryptography and, like TSIG, can be used to secure transactions between and and between and client. TSIG secures the communications between two name s or between an updater and a name but does not protect your system if one of your name s is compromised. Someone breaking into one of your name s may gain access to the TSIG keys. Moreover, because TSIG uses shared secrets, it is not practical to configure TSIG among many name s. You could not use TSIG to secure your name s communication with arbitrary name s on the Internet because it is impossible to distribute and manage that many keys. The most common way to deal with key management problems is to use public key cryptography. The DNS Security Extensions (DNSSEC) use public key cryptography to enable zone administrators to digitally sign their zone data, thereby proving the zone data s authenticity. The DNS Security Extensions (DNSSEC) defined in RFC 2535 Domain Name System Security Extensions are found at BIND provides several tools to set up a DNSSEC secure zone. Communication must exist between 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 s 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 zone on the DNS tree. In DNSSEC, each secure zone has a key pair associated with it. The zone's private key is stored somewhere safe, often in a file on the name 's file system. The zone's public key is advertised as a new type of record attached to the domain name of the zone, the KEY record. The KEY record is a general-purpose record. You can use the KEY record to store different kinds of cryptographic keys, not just the zone's public keys for use with DNSSEC. If the KEY record stores a zone's public key, a new record must exist to store the corresponding private key's signature. That new record is the SIG record. DNSSEC also introduces another new record type: the NXT record. Output from dig shows that DNSSEC increases the average size of a DNS message, that it requires substantially more computational horsepower from name s verifying zone data, and that signing a zone increases the zone s size substantially. Current estimates are that signing multiplies the size of a zone by a factor of seven. For this reason, if you plan to sign your zones, make sure your authoritative name 3-20

63 DNS Configuration on the NonStop Server Use Public Key Cryptography: DNSSEC s have enough memory to load the new, larger zones. If your name s are resolving more records in secure zones, make sure they have enough processor power to verify all those digital signatures and remember that BIND 9 can take advantage of any processors you can add to the host it runs on. Note. The trusted-keys statement in the BIND 9 configuration file syntax is used to configure the public keys of security roots for use in DNSSEC. Generating a Key Pair The first step in DNSSEC configuration is generating a key pair (public key and private key). Use the command dnssec-keygen: $> -keygen -a RSA -b 512 -n ZONE myzone.com. The output for this command is: Kmyzone.com The command generates two files containing the public and private keys. The public key is contained in output.key. The private key is contained in the file output.private and where output is the output (shown above) that is printed by the dnssec-keygen tool. Signing the Zone File The zone file to be signed and the key files (output.key and output.private) must be in the same directory. Append the public key to the existing zone file: $> cat "$INCLUDE Kmyzone.com key" >> db.myzone.com This command creates the KEY records in the signed zone file and also instructs dnssec-signzone to use the private key file to sign the zone file. Sign the zone: $> dnssec-signzone -o myzone.com db.myzone.com The output of this command is the signed zone file named db.myzone.com.signed. Alter the existing name configuration file (named.conf) to include the signed zone file: zone "myzone.com" in { type master; file "db.myzone.com.signed"; }; 3-21

64 DNS Configuration on the NonStop Server Managing Persistence for the named Process Specifying a Trusted Key For the name s requiring secure communication with the above configured name, you must add a trusted-keys statement in their configuration files (named.conf). The following example shows the trusted-keys statement for the named.conf file of the affected name : trusted-keys { myzone.com signature; }; The above statement specifies that the name trusts the listed public key for signature verification for the zone, myzone.com. The signature must be manually exchanged between the name s. Managing Persistence for the named Process The NonStop Kernel Persistence Manager ($ZZKRN) provides support for making HP NonStop Open System Services (OSS) processes persistent, starting with the G06.24 RVU. This feature of $ZZKRN can be used in making DNS persistent. Configuring the named Process as a Persistent Process Use the Subsystem Control Facility (SCF) to configure the name (named process) to $ZZKRN. Perform this procedure in the Guardian environment. 1. Add named to the system configuration database (this example is for nonsecure DNS, for secure DNS, the directory for named is /etc/dns_secure: ->add process $zzkrn.#named, name $osh, autorestart 10, & cpu firstof (1,0), startmode manual, userid super.super, & program $system.system.osh, assocproc $dns12, & hometerm $ZHOME, startupmsg & -ls -name /G/dns12 -osstty -p /etc/dns923/named -g -f For information about the attributes shown in this command example, see the SCF Reference Manual for the Kernel Subsystem in NTL. 2. Start the $ZZKRN.#named process: ->start process $zzkrn.#named 3-22

65 DNS Configuration on the NonStop Server Stopping the named Process as a Persistent Process Stopping the named Process as a Persistent Process 1. To stop the named process if it is configured as a persistent process (autorestart > 0), issue the SCF ABORT command to the NonStop Kernel subsystem as shown: ->abort process $zzkrn.#named For more information about managing persistence, see the SCF Reference Manual for the Kernel Subsystem in NTL. Specifying a TCP/IP Process by Using a Runtime Option By default, the named process binds to the TCP/IP process $ztc0. To make the named process use the TCP/IP process that is specified at runtime, a runtime option (-T) is provided (the -T option takes the name of the TCP/IP process that is to be used by named). No checking is done by named for the validity of the process name. If you specify an invalid TCP/IP process name, the named process will not start. If you do not specify the -T option, named gets bound to $ztc0. To run named on the TCP/IP process $ztcp2: /etc/dns923> named -T \$ztcp2 Specifying a Different resolv.conf File The resolver uses the /etc/resolv.conf file by default. The new environment variable TCPIP_RESOLVER_NAME must be used for pointing to the resolv.conf file; this variable can be set either through the OSS shell prompt or through a call to the putenv() procedure in the OSS application. The following pieces of code are examples of resolving the destination host by querying the name pointed at by the /etc/dns/resolv.conf file. 3-23

66 DNS Configuration on the NonStop Server Specifying Multiple Names in the Resolver by Using Sections Example 3-4. Specifying a Different resolv.conf File Through an Application putenv ("TCPIP_RESOLVER_NAME=/etc/dns/resolv.conf"); h = gethostbyname(argv[1]); if(h==null) { printf("%s: unknown host '%s'\n",argv[0],argv[1]); exit(1); } Example 3-5. Specifying a Different resolv.conf File Through the OSS Shell /etc/dns923> export TCPIP_RESOLVER_NAME= /etc/dns/resolv.conf /etc/dns923> set Specifying Multiple Names in the Resolver by Using Sections The resolver configuration file is used by the resolver library to get the default local domain name and the IP addresses of name s to contact. The resolver configuration file is named resolv.conf in OSS and RESCONF in Guardian, but the syntax and usage is the same for both the environments. In addition to the existing domain and name directives, the following new directives have been provided to be used in the resolver configuration file: Name Server Specifies the internet address of a Name Server in dot-notation format. In addition to the ability to specify IPv4 addresses, you can now provide IPv6 addresses with the Name Server directive. search Provides a search list for host name lookup The default behavior provided by the domain directive can be changed by listing the desired domain search path following the search keyword, with spaces or tabs separating the names. Most resolver queries are attempted using each component of the search path in turn until a match is found. The search list is limited to six domains. 3-24

67 DNS Configuration on the NonStop Server Specifying Multiple Names in the Resolver by Using Sections options Allows internal resolver variables to be modified. The most common variables that can be modified are ndots, timeout, retrans, attempts, retry. Note. For more information about the above directives, refer to the resolv.conf man page. (See Table 2-1, OSS Commands to Access man Pages, on page 2-3.) This feature allows you to search for host-names in multiple domains and their respective name s. This search is done by using the introduction of a new keyword section in the resolver configuration file. This section is a sub-part of the resolver configuration file that specifies: The domain to be searched as specified by the keyword domain. The Name Servers to be contacted as specified after the domain statement. The section can also specify the other resolver directives: search and options. Thus, a section can incorporate all directives that are part of a resolver configuration file. Example 3-6. Resolver Configuration File With Sections domain abc.com name section domain def.com name section domain ghi.com name The first two lines (specifying domain and name) of Example 3-6 form the default section for which the keyword section is not needed. The subsequent sections have to be specified by the keyword section as shown. A maximum of five sections, including the default section, can be specified. Note. The search keyword can be used instead of domain to specify a list of domain names in the resolver file. For details about the use of the search keyword, refer to the resolv.conf MAN page. (See Table 2-1, OSS Commands to Access man Pages, on page 2-3.) When a query is issued to resolve a host name, the DNS resolver sequentially appends each of the domains (specified with the keyword domain) to the host name. 3-25

68 DNS Configuration on the NonStop Server Tips and Important Tasks The query is then sent to the listed name s until the host name is resolved or all listed name s have been tried. For example, the host-name is machine1, machine1.abc.com is sent to the name running on If the host name is not resolved by this name, the next section of resolv.conf is used. That is, machine1.def.com is sent to the name running on This process continues till the host name is resolved or all the sections have been tried. Tips and Important Tasks If you modify the named.conf file or zone files, the changes do not take effect until you stop and restart named or tell named to reread its configuration. (rndc reload or rndc reconfig. For more information, see the rndc man page.) To use TSIG, both rndc and named need to configure the shared key that they are using. If you are using IPv6 addresses, start NonStop TCP/IPv6 in DUAL mode and set the options statement in the named.conf file to listen-on-v

69 4 Scaling DNS You can scale DNS in two ways: by separating traffic over physical networks by using the DNS round-robin address rotation feature. Physical Network Separation Network scalability refers to distributing incoming requests across multiple network interfaces. You can achieve network scalability by having multiple network interfaces on multiple hosts/s or by having a multi-homed host (a system that has multiple network interfaces). In a multi-homed system where you have multiple interfaces on multiple subnets and where you want the system to appear to be one name while also distributing the network traffic, you can configure DNS so that a different IP address is returned depending on the subnet when queries for that name are received. One way to accomplish this task is to run a copy of the DNS on each subnet, and on each subnet return the IP address of the interface that is on that subnet. This arrangement is a kind of physical scaling because you are servicing clients based on the subnet on which the client resides. For example, assume you have four DNS name s, one on each subnet configured to return the IP address of the host s interface on that subnet. All clients requesting an IP address on that subnet are returned the IP address of the host that is also on that subnet: Clients on subnet requesting the IP address of MyCompany.com receive the IP address of Web 1. Clients on subnet requesting the IP address of MyCompany.com receive the IP address of Web 2. Clients on subnet requesting the IP address of MyCompany.com receive the IP address of Web 3. Clients on subnet requesting the IP address of MyCompany.com receive the IP address of Web

70 Scaling DNS DNS Round-Robin Address Rotation Figure 4-1. Physical Separation of Network Traffic Four s for MyCompany Web 1 Web 2 Web 3 Web 4 DNS (named) 1 DNS (named) 2 DNS (named) 3 DNS (named) 4 Subnet DNS 1 returns IP address of We 1 Subnet DNS 2 returns IP address of We 2 Subnet DNS 3 returns IP address of We 3 Subnet DNS 4 returns IP address of We 4 vst028.vsd Note. Figure 4-1 shows the processors as separate s to illustrate a general concept. In the NonStop environment, all four processors could be in one. This arrangement is a physical scaling mechanism appropriate for private networks. DNS Round-Robin Address Rotation Another method of scaling at the network level is to use DNS round-robin address rotation. For DNS address rotation, a different network interface is associated with each IP address, and one name answers requests for the name using the 4-2

71 Scaling DNS DNS Round-Robin Address Rotation different IP addresses on a rotating basis. This method of dividing network traffic uses a DNS feature called DNS round-robin address rotation. Note. Round-robin address resolution is the default DNS configuration; unless you add an option statement to the named.conf file that specifies no-round-robin, round-robin address resolution is enabled. Figure 4-2. DNS Round-Robin Address Rotation Four s for MyCompany.com Web 1 Web 2 Web 3 Web 4 DNS (named) The name returns the IP addresses of the WebServers for MyCompany.com on a rotating basis so that the network traffic is distributed among the four network interfaces vst029.vsd This method is appropriate for a public network. 4-3

72 Scaling DNS DNS Round-Robin Address Rotation 4-4

73 5 Troubleshooting This section provides guidelines for troubleshooting various problems you may encounter with DNS. This section contains the following information: Troubleshooting DNS on page 5-1 Logging in DNS on page 5-3 Troubleshooting DNS In most cases, the primary cause of the process named failing to start is faulty configuration. The best way of troubleshooting this error is to set up logging beforehand; the log files provide hints and information that can be used to determine what went wrong. Refer to Logging in DNS on page 5-3 for the description of the DNS logging mechanism. Alternatively, a more interactive and simpler (but not as detailed) way to troubleshoot errors is to start named with the -g option. This approach causes the to be run in the foreground and all logging is forced to stderr. The following is a sample named.conf (configuration) file with various syntax errors; line numbers are shown for convenience. 5-1

74 Troubleshooting Troubleshooting DNS Example 5-1. Sample named.conf File 1 /*Sample configuration file */ 2 3 options { 4 directory "/user/dns/nameddir"; 5 pid-file "named.pid" /*semicolon missing*/ 6 listen-on { ; }; 7 }; 8 9 logging { 10 channel my_syslog { 11 syslog demon; 12 severity info; 13 } /*semicolon missing*/ channel my_file { 16 file "log.msgs"; 17 severity dynamic; 18 }; category statistics { my_ems; my_file; }; 21 category queries { my_ems; my_file; }; 22 }; zone "myzone.com" in { 25 type master; 26 file "db.myzone.com"; 27 }; 28 /*Sample configuration file ends*/ When named is run with the -g option using the above configuration, the following is displayed: Aug 30 10:26:14.0lu /etc/named.conf:5: missing ';' before 'pid-file' Aug 30 10:26:14.0lu /etc/named.conf:13: missing ';' before '}' Aug 30 10:26:14.0lu loading configuration: failure Aug 30 10:26:14.0lu exiting (due to fatal error) 5-2

75 Troubleshooting Logging in DNS As shown, the error is displayed along with date, time and line numbers (5 and 13 in this case). Logging in DNS There are two main phrases in logging: Channels specify where the data is logged. Categories specify what kind of data (queries, updates, statistics, and so on) has to be logged in specified channels. Standard channels are: file syslog stderr null Standard categories are: default general database security config resolver xfer-in xfer-out notify client unmatched network update queries dispatch lame-s Each category of data can be sent to one or more channels. In Figure 5-1, queries are logged to a file, and statistics data is logged both to a file and to syslog. 5-3

76 Troubleshooting Logging in DNS Figure 5-1. Logging Categories to Channels statistics category syslog channel queries category log_file channel vst001.vsd The name can be instructed to enable this feature by specifying the logging statement in the named.conf file. Example 5-2 shows a statement in the named.conf file. Example 5-2. Logging Statement in named.conf File logging { }; channel my_ems { }; syslog demon; severity info; channel my_file { }; file "mylog.log"; severity dynamic; category statistics { my_ems; my_file; }; category queries { my_file; }; In this example, two channels have been defined: my_ems instructs the name to send logging data to the Event Management System (EMS). my_file instructs the name to send logging data to the file mylog.log. Similarly, two categories have been defined: 5-4

77 Troubleshooting Logging in DNS statistics instructs the name to send the statistical data to both EMS and a local file. queries instructs the name to send the logging data on queries to a local file only. Refer to the BIND 9 Administrator Reference Manual in NTL for additional information on the logging statement, channels, and categories. 5-5

78 Troubleshooting Logging in DNS 5-6

79 A DNS and BIND Basics The Berkeley Internet Name Domain (BIND) is a Berkeley implementation of the Domain Name System (DNS). BIND is a distributed-network, information-lookup service that maps host names to Internet addresses and maps Internet addresses to host names. BIND also facilitates Internet mail routing by supplying a list of hosts that accept mail for other hosts. This appendix describes the BIND features and components and how they work. It contains: Components of DNS on page A-1 How BIND Works on page A-4 The BIND Configuration File on page A-18 Components of DNS DNS consists of: DNS Name Space on page A-1 The Resolver on page A-3 The Name Server on page A-3 Lightweight Resolver Library and Demon on page A-4 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 indigo in the div domain is indigo.div.inc.com. Figure A-1 shows the hierarchical structure of the DNS name space. A-1

80 DNS and BIND Basics DNS Name Space Figure A-1. Structure of the DNS Name Space host.(root) domain com edu inc nmt purdue div cs econ venus indigo arthur VST002.vsd 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 has authority over. Normally, a zone does not contain any delegated subdomains, whereas a domain can contain data delegated to other name s. Therefore, as long as subdomains are not delegated, a zone and a domain contain the same data. DNS Change Notification BIND supports DNS change notification, also known as DNS Notify, which allows master s to inform slave s that new information is available. In the original DNS protocol, slave s (secondaries) polled the master at intervals defined in the Start of Authority (SOA) record. At these defined intervals, the slave checked the SOA record on the master to find out if the serial number changed. If the slave 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 to notify slave s that a zone transfer is necessary. DNS Notify uses a new DNS opcode. The notification is sent to all the hosts listed as name s in the name (NS) records for the zone. Additionally, BIND allows you list additional s to accommodate stealth s, which are not listed in any name records. You can use the zone statement to list these additional s in the configuration file, named.conf. When a slave 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 A-2

81 DNS and BIND Basics The Resolver SOA record from the master and then initiating a zone transfer if the record has changed). The DNS Notify feature is enabled in the master by default. In some environments, the master in a zone may be an or later with DNS Notify enabled, while the other s in the zone are 4.x s (without the DNS Notify feature). In such environments, whenever the master changes and sends a notification to other s, the 4.x s ignore this notification because they do not understand the DNS Notify protocol. Dynamic DNS Update See Section 2, BIND 9.x on the NonStop Server for information about dynamic update. Incremental Zone Transfer (IXFR) See Section 2, BIND 9.x on the NonStop Server for information about IXFR. The Resolver Resolvers match host names to IP addresses and IP addresses to host names. The resolver is the client portion of the Domain Name System. A resolver queries a name for data and is responsible for: Translating an application's request for data into a DNS query packet and then sending the packet to a name Retransmitting the packet, possibly to another name, if the queried name does not respond The Name Server The name is the demon named. The named demon is a program that has information about the domain's tree structure and database information. By extension, hosts on which the named process runs are also called name s. Name s respond to queries either from resolvers or from other name s. The name that the resolver initially contacts does most of the work, but the name may need to contact other name s for direction and information. Configured name s provide the following functionality: Know the name (s) for the root of the DNS tree Respond to queries for DNS name space data Query other name s to find data elsewhere in the name space Types of Name Servers Most DNS s play multiple roles: they may be masters (authoritative) for some zones, slaves for others, and provide caching or forwarding for all others. A-3

82 DNS and BIND Basics Lightweight Resolver Library and Demon If the named process is configured as a persistent process, the system automatically starts it upon reload or whenever the process is stopped. Alternatively, you can start it at the command line or by running a script. The named process, when it starts, reads the named.conf to determine: If the is a master, slave, or cache-only domain name for the specified domains. In which local files, if any, the domain information resides, and what are the IP addresses of the root, master, and delegated s. This data is in the form of resource records (RRs) The s for a particular domain do not have to belong to that domain. For example, the slave namesvr2.hp.com can contain the resource record for the domain animals.hp.com. No resolution problem occurs because the IP addresses of the s are always configured. When a receives a query for an external domain, it first contacts the root to find the nearest to the target domain. The local then contacts this remote, which either provides the requested information or a referral address of another. The then caches both the remote s addresses and the data returned in the resource record (RR). At configurable intervals, this cached data times out. You can configure a host as any of the following types of BIND name s: Master Slave Cache-only Forwarding Lightweight Resolver Library and Demon See Section 2, BIND 9.x on the NonStop Server for information about the lightweight resolver library and demon. How BIND Works This subsection describes how the name resolves host names, including the following topics: Overview on page A-4 The Resolution Process on page A-6 Overview BIND operates through resolution. Resolution is the process by which name s locate data in the name space. A resolver seeks an answer to one specific question. A-4

83 DNS and BIND Basics Overview Typically, the client resolver gives a DNS node name and requests as an answer the node s IP address, or the client resolver gives a DNS node name s IP address and requests as an answer the node s name. However, the name may have different data it is seeking, such as addresses of other domain name s. When a DNS receives a query for a name that is in a zone for which it is not authoritative, it first checks its cache to see if it has already resolved the address being queried. If the address has not been resolved, the DNS checks the cache again for the address of an authoritative name for the domain. Finally, if it has no name information (based on previous queries), it checks the list of root name s that it derived from db.cache when the DNS was started. This file lists the name s that are queried for a list of root s. It then sends the query to one of the root s. BIND functions in the following ways: Top down approach If the name contacted has no information, that name asks a root name for the information. The root name refers the querying name to another name closer to the answer. This process continues until an answer is found. Query approach DNS name s query other name s anywhere in the name space to obtain the answer to the query. Referral and response approach Queries are requests for a certain type of data attached to a particular domain name. Referrals tell a name to go query a different name for the answer. Responses provide the data requested or an error. Consider the structure of the DNS name space shown in Figure A-1 on page A-2. When a user logged in to host venus in the nmt.edu domain types, 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 s. 3. The resolver constructs a query and sends it to a name. If the local host is not running a name, the local host must contain a file called /etc/resolv.conf, which contains one or more Internet addresses for name s 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. A-5

84 DNS and BIND Basics The Resolution Process 4. The name demon, named, receives the query from the resolver. Because the name has information about only the hosts in its local domain (nmt.edu), it cannot answer the query using the information in its local database. 5. The local name queries a root name to find the address of indigo.div.inc.com. The root name serves the root domain. The root name typically stores information about hosts and name s one and two levels below the root. 6. If the root name cannot resolve the host name, it returns the address of a name for the inc.com domain. 7. The local name queries the for the inc.com domain to find the address of indigo.div.inc.com. 8. The name for the inc.com domain may not contain information for the div.inc.com domain. If so, it returns the address of a name for the div.inc.com domain. 9. The local name queries the for the div.inc.com domain to find the address of indigo.div.inc.com. 10. The for the div.inc.com domain returns the address of indigo.div.inc.com to the local name. 11. The local name passes host indigo s address to the resolver, which passes the address to gethostbyname, which returns the address to the telnet process. The local name in the nmt.edu domain caches the addresses of the remote name s, so that the next time a local user needs the address of a host in the inc.com domain, the local name sends its query directly to the name for inc.com instead of querying the root name. The Resolution Process This subsection describes various aspects of the BIND resolution process. BIND allows you to enter host names that are not fully qualified because typing complete domain names is cumbersome; that is, host names that do not contain every label from the host to the root and end with a dot. 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 mail addresses and network-related configuration files. To facilitate the lookup process, you can use names that contain all the name components and end with a dot in commands like dig, ping, and telnet. To resolve a host name, BIND uses the following methods: If the input host name ends with a dot, the name looks up the input host name 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 A-6

85 DNS and BIND Basics The Resolution Process the host name. (The default value of ndots is 1; therefore, if the input host name contains one dot, the input host name is looked up as is before any domains are appended to it.) If the input host name contains a single component (that is, the 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. If the input host name does not end with a dot, BIND looks up the input host name 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 search option in the /etc/resolv.conf file. The domain option in the /etc/resolv.conf file. 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 specify the search option. If you use both the domain and search options in the /etc/resolv.conf file (or RESCONF 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 resolver configuration files. See the TCP/IPv6 Configuration and Management Manual for information about the RESCONF file (the Guardian version of resolv.conf) and the Open System Services Management and Operations Guide for procedures to create a symbolic link to the RESCONF file. How the Resolver Functions A resolver is a set of procedures called by any process that needs to ask questions of a DNS. Programs running on a host that need information from the domain name space use the resolver. These programs are sometimes running on the same system as the name. Resolvers question the DNS, based on the configuration in /etc/resolv.conf. This configuration tells the resolver whether to ask DNS look in /etc/hosts. So the resolver could actually get information about hostname and IP address using DNS or the /etc/hosts file. The resolver handles the following tasks: Builds a list of possible absolute domain names in case the requested name is a relative domain name. Queries the name locally or on a remote host configured in /etc/resolv.conf to translate the domain name into IP address(es). The resolver retransmits the packet, possibly to another name, if the queried name does not respond A-7

86 DNS and BIND Basics The Resolution Process Interprets responses (which may be resource records or an error). Returns the information to the programs that requested it. Each time a service is invoked, such as Telnet or FTP, specifying a target hostname, you indirectly launch a resolver routine like gethostbyname(). The networking software uses IP addresses, not names. The host name must be resolved or mapped to an IP address. Although the resolver converts a target hostname to an IP address, the resolver routines also convert IP addresses to names (reverse lookups) and obtain mail routing information (MX record lookups), among other tasks. Name Servers: Recursive and Nonrecursive Resolution There are two forms of query resolution that a name may be requested to perform: Recursive This form of resolution places the burden on the queried name receiving the request. For a recursive query, the sender does not expect any reply except for the ultimate answer. The queried name must respond with the data or an error indicating that the data does not exist. The queried name cannot respond with a referral to another possible source of information. The sender of a recursive query anticipates that the will make any further queries on the sender's behalf that are necessary to obtain an answer. Client resolvers issue this type of query. The request is sent by the resolver as recursion requested. Figure A-2 through Figure A-11 show a ten-step, recursive resolution process. Nonrecursive (iterative) This form of resolution enables the queried name to respond by identifying another name if the queried name does not have the requested information. A referral response provides the name and IP address of one or more name s that should be contacted. A name makes nonrecursive queries and acts iteratively. A-8

87 DNS and BIND Basics The Resolution Process 1. The client resolver sends the query request to the local name. (In this example, a recursive query for is sent.) Figure A-2. Recursive Query Is Sent by the Client Resolver local name "root" name. edu com client resolver edu name mit... mit.edu name VST014.vsd A-9

88 DNS and BIND Basics The Resolution Process 2. The local name receives the recursive query request from the resolver supporting the client TCP/IP program and asks a name in its domain to resolve the domain name to an IP address. Figure A-3. Local Name Server Receives Recursive Query local name "root" name. edu com client resolver edu name mit... mit.edu name VST015.vsd A-10

89 DNS and BIND Basics The Resolution Process 3. The requested name is not a local one, and it is not in the cache of the, so the request goes to the root. (In this example, the name sends a nonrecursive query to the root for address Figure A-4. Name Server Sends Nonrecursive Query to Root local name "root" name. edu com client resolver edu name mit... mit.edu name VST016.vsd A-11

90 DNS and BIND Basics The Resolution Process 4. The root provides the best answer it can: a referral that gives the address of the next closest name to the destination (edu). This action begins the iterative part of the resolution process. Figure A-5. Root Server Refers Local Name Server to a Closer Server local name "root" name. edu com client resolver edu name mit... mit.edu name VST017.vsd A-12

91 DNS and BIND Basics The Resolution Process 5. The next name is queried (nonrecursively). (In this example, the local name sends a query to edu for the address of Figure A-6. Local Name Server Sends Query to Referred Server local name "root" name. edu com client resolver edu name mit... mit.edu name VST018.vsd A-13

92 DNS and BIND Basics The Resolution Process 6. The next name is queried (nonrecursively), and it responds with a referral to the next. (In this example, the edu name sends a referral to mit.edu.) Figure A-7. The Next Server Refers Local Server to Next Closer Server local name "root" name. edu com edu name mit... client resolver mit.edu name d VST019.vsd A-14

93 DNS and BIND Basics The Resolution Process 7. The local name sends its query to the next. (In this example, the local name sends a nonrecursive query to mit.edu for the address of Figure A-8. Local Server Sends Query to Next Referred Server local name "root" name. edu com edu name mit... client resolver mit.edu name VST021.vsd A-15

94 DNS and BIND Basics The Resolution Process 8. The responsible for the requested domain is reached. The provided answer is an authoritative answer. This answer is authoritative because this has the complete set of information for the requested domain. (In this example, the mit.edu name returns the IP address of Figure A-9. Authoritative Server Returns IP Address to Local Server local name "root" name. edu com edu name mit... client resolver mit.edu name VST022.vsd A-16

95 DNS and BIND Basics The Resolution Process 9. The local sends the IP address to the client resolver. (In this example, the local name answers the recursive query for with the IP address of Figure A-10. Local Server Answers Original Request local name "root" name. edu com edu name mit... client resolver mit.edu name VST023.vsd A-17

96 DNS and BIND Basics The BIND Configuration File 10. The client resolver receives the IP address to Figure A-11. Client Resolver Receives IP Address of Requested Server local name "root" name. edu com edu name mit... client resolver mit.edu name VST024.vsd The BIND Configuration File The BIND configuration file, named.conf, enables you to specify many features by using statements and comments. Each statement in the configuration file ends with a semicolon. Many statements contain a block of sub-statements, 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). The /etc/named.conf Statements The following statements are supported in the named.conf file: The acl statement The include statement The key statement The logging statement A-18

97 DNS and BIND Basics The /etc/named.conf Statements The options statement The statement The zone statement The view statement The sortlist statement The acl statement is discussed further in Use ACLs on page 3-9, logging is discussed in Logging in DNS on page 5-3, and the options statement is discussed in Section 2, BIND 9.x on the NonStop Server as well as in the BIND Administrator Reference Manual. The options statement is complex, currently containing 84 configurable options. (The allow-update and update-policy statements are mutually exclusive, however.) The current list of supported options is organized in BIND Administrator Reference Manual in functional groups. This organization is shown here to facilitate discussions of DNS configuration within this manual. The categories are: Periodic Task Intervals on page A-21 Topology on page A-21 The sortlist Statement on page A-22 RRset Ordering on page A-22 Synthetic IPv6 Responses on page A-22 Tuning on page A-22 The Statistics File on page A-22 options Statement Definition and Usage This category is a catch-all for options that do not fit in the other categories. Options described in this category include: version directory named-xfer tkey-domain tkey-dhkey dump-file memstatistics-file pid-file statistics-file (also described in The Statistics File on page A-22) port random-device A-19

98 DNS and BIND Basics The /etc/named.conf Statements Boolean Options auth-nxdomain deallocate-on-exit dialup fake-iquery fetch-glue has-old-clients host-statistics maintain-ixfr-base minimal-responses multiple-cnames notify recursion rfc2308-type1 use-id-pool zone-statistics use-ixfr provide-ixfr request-ixfr treat-cr-as-space Forwarding forward forwarders Access Control allow-notify allow-query allow-recursion allow-v6-synthesis (also described in Synthetic IPv6 Responses on page A-22) allow-transfer blackhole Interfaces listen-on listen-on-v6 Query Address query-source query-source-v6 A-20

99 DNS and BIND Basics The /etc/named.conf Statements (query-source-v6 is not shown in the Options Statement Grammar section of the BIND Administrator Reference Manual but is described in the subsection Query Address.) Zone Transfers also-notify max-transfer-time-in max-transfer-idle-in max-transfer-time-out max-transfer-idle-out serial-query-rate serial-queries transfer-format transfers-in transfers-out transfers-per-ns transfer-source transfer-source-v6 notify-source notify-source-v6 Operating System Resource Limits coresize datasize files stacksize Server Resource Limits max-ixfr-log-size recursive-clients tcp-clients max-cache-size Periodic Task Intervals cleaning-interval hearbeat-interval interface-interval statistics-interval Topology This category describes an option not available in BIND 9. A-21

100 DNS and BIND Basics The /etc/named.conf Statements The sortlist Statement sortlist RRset Ordering rrset-order Synthetic IPv6 Responses allow-v6-synthesis Tuning lame-ttl max-ncache-ttl max-cache-ttl min-roots sig-validity-interval max-refresh-time min-retry-time max-retry-time The Statistics File statistics-file A-22

101 B DNS Server Configuration This appendix describes configuring the master. Topics include: Master Server Configuration File on page B-1 Master Server Cache File on page B-4 The db File on page B-8 Master Server db.domain Files on page B-10 Master Server Configuration File The configuration file, named.conf, informs the master of the location of all the required data files. The master name loads its database from these data files. You create the named.conf by using a text editor. If you are running one master, create the configuration file in /etc/dns_secure/named.conf or /etc/dns923/named.conf. If you are running multiple master s, each one must have a different configuration file, the location of which you specify by using the -c option when starting the. (Since the default location for the named.conf file is /etc/named.conf and the examples in this manual use the /etc/dns_secure/ directory, the -c directive must be used to start all the master s.) An example of configuring a second master follows Example B-1. For the setup in Figure B-1, the /etc/hosts file is: rabbit localhost loopback cheetah indigo incindigo B-1

102 DNS Server Configuration Master Server Configuration File Example B-1. Configuration File for Master Server Authoritative for Domain div.inc.com and Network # # type domain source file # option { directory "/etc/dns-secure/named.data"; }; zone " IN-ADDR.ARPA" { type master; file "db "; }; zone "div.inc.com" { type master; file "db.div"; }; zone " IN-ADDR.ARPA" { type master; file "db "; }; zone "." { type hint; file "db.cache"; }; Figure B-1 shows the structure of a master and a slave. Figure B-1. Structure of a Master Server and Slave Servers Master rabbit.div.inc.com Slave indigo.div.inc.com Slave cheetah.div.inc.com VST003.vsd B-2

103 DNS Server Configuration Master Server Configuration File Example B-2. named.conf Sample File // type domain source file // // option { directory "/etc/dns-secure/named.data"; }; zone " IN.ADDR.ARPA" { type master; file "db "; }; zone "div.inc.com" { type master; file "db.div"; }; zone " IN.ADDR.ARPA" { type master; file "db "; }; zone "." { type master; file "db.root"; }; The fields used in this sample named.conf are (lines beginning with double slashes (//) are comments): directory zone type indicates the directory where data files are located. defines the zone for that domain. defines the zone type. B-3

104 DNS Server Configuration Master Server Cache File file specifies the database file for that zone. If you are moving your name data and configuration files from earlier versions of BIND 4.x to this version, 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 using the following command: /etc/dns923> named-bootconf.sh < named.boot > named.conf Master Server Cache File The cache file, /etc/dns_secure/db.cache, lists the root name s for the root domain. Each name must have a cache file. When a name cannot resolve a host name query from its local database or its local cache, the name queries a root. (Obtain a list of root name s from rs.internic.net by using anonymous ftp.) B-4

105 DNS Server Configuration Master Server Cache File Following is a sample db.cache file for a master : ; This file holds the information on root name s ; needed to initialize cache of Internet domain name s ; (for example, reference this file in the "cache.<file>" ; configuration file of BIND domain name s). ; This file is made available by InterNIC registration ; services under anonymous FTP as ; file /domain/named.root ; on FTP.RS.INTERNIC.NET ; ; last update: Nov 5, 2004 ; related version of root zone: ; ; formerly NS.INTERNIC.NET ; name ttl class type data ; IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A ; ; formerly NS1.ISI.EDU ; NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET A ; ; formerly C.PSI.EDU ; NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET A ; ; formerly TERP.UMD.EDU ; NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET A B-5

106 DNS Server Configuration Master Server Cache File ; ; formerly NS.NASA.GOV ; NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET A ; ; formerly NS.ISC.ORG ; NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET A ; ; formerly NS.NIC.DDN.MIL ; NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET A ; ; formerly AOS.ARL.ARMY.MIL ; NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET A ; ; formerly NIC.NORDU.NET ; NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET A ; ; operated by VeriSign, Inc ; ; NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET A ; ; housed in LINX, operated by RIPE NCC ; ; NS K.ROOT-SERVERS.NET. B-6

107 DNS Server Configuration Master Server Cache File K.ROOT-SERVERS.NET A ; ; temporarily housed at ISI (IANA) ; NS L.ROOT-SERVERS.NET L.ROOT-SERVERS.NET A ; ; housed in Japan, operated by WIDE ; NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET A The fields used in the db.cache file are (lines beginning with a semicolon (;) are comments): name ttl class type For NS records, name specifies the name of the domain served by the name 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 (address) records, the name column contains the name of the name whose address appears in the data column. The optional time-to-live (ttl) indicates how long (in seconds) a caches the data received in response to a query. 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 s. The first field in an NS record is the domain for which the name has authority. The last field in an NS record is the fully qualified name of the name. For records of type A list, the first field in an A record is the name of the name. The last field in an A record is the Internet address of the name. B-7

108 DNS Server Configuration The db File data The data field for an NS record provides the fully qualified name of a name. The data field for an A record specifies an Internet address of the name. The db File Each name must have an /etc/dns_secure/db file. Hosts running Berkeley networking use as the address of the loopback interface. Because the network number is not assigned to any site but is used by all hosts running Berkeley networking, you must configure each name as authoritative for the network The file /etc/dns_secure/db contains the resource record that maps to the name of the loopback address, usually localhost. Use a text editor to create the db file. The following is a sample db file: ;name class type data $TTL IN SOA rabbit.div.inc.com root.moon.div.inc.com ( 1 ; Serial ; Refresh every 3 hours 3600 ; Refresh every hour ; Expires after a week ) ; Minimum ttl of 1 day IN NS rabbit.div.inc.com 1 IN PTR localhost The fields in the db file are: name 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 represents in-addr.arpa. Similarly, for the PTR record, 1 represents in-addr.arpa. in the expanded notation. class type 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 is authoritative for the data in the domain. B-8

109 DNS Server Configuration The db File $TTL The NS record designates a name for the current origin ( inaddr.arpa). PTR records are usually associate an address in the in-addr.arpa domain with the canonical name of a host. The PTR record in the example db file associates the name localhost with the address 1, that is, inaddr.arpa. (The current origin 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, and the following values: Serial indicates the version number of this file, incremented whenever you change the data. Refresh Retry indicates (in seconds) how often a slave name must update its data from a master. indicates (in seconds) how often a slave must retry after an attempted refresh fails. Expire indicates (in seconds) how long the slave name can use the data before the data expires for lack of a refresh. Minimum ttl indicates (in seconds) the minimum number of seconds the name is allowed to cache data. After the time-to-live (ttl) value expires, the name must discard the cached data and obtain new data from the authoritative name s. The NS data is the fully qualified name of the name. The PTR data is the loopback address of localhost, in the in-addr.arpa domain. indicates (in seconds) the time-to-live (ttl) value for records that do not have the ttl value defined in the data field. B-9

110 DNS Server Configuration Master Server db.domain Files Master Server db.domain Files A master has one /etc/dns-secure/db. domain file for each domain for which it is authoritative. This file must contain an A (address) record for every host in the zone. Example B-3. Sample db.domain File ; ; db.div ; $TTL IN SOA rabbit.div.inc.com root.moon.div.inc.com ( 1 ; Serial ; Refresh every 3 hours 3600 ; Retry every hour ; Expires after a week ; Minimum ttl of 1 day IN NS rabbit.div.inc.com IN NS indigo.div.inc.com localhost IN A indigo IN A IN A IN HINFO HP9000/840 HPUX incindigo IN CNAME indigo cheetah IN A IN HINFO HP9000/850 HPUX IN WKS UPD syslog domain route IN WKS TCP (telnet smtp ftp shell domain) rabbit IN MX 5 rabbit.div.inc.com IN MX 10 indigo.div.inc.com rabbit IN A The sample 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 is authoritative for the data in the domain. The at sign (@) represents 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 named.conf configuration file. The named.conf file denotes that the div.inc.com domain is configured in the db.div file. Therefore, every instance in the db.div file represents div.inc.com. B-10

111 DNS Server Configuration Master Server db.domain Files The SOA record specifies the name of the host this data file was created on, an electronic mail address of the name s technical contact, and the following values: Serial indicates the version number of this file, incremented whenever the data is changed. Refresh Retry indicates (in seconds) how often a slave name must try to update its data from a master. indicates (in seconds) how often a slave must retry after an attempted refresh fails. Expire indicates (in seconds) how long the slave name can use the data before it expires for lack of a refresh. Minimum ttl indicates the minimum number of seconds the name is allowed to cache data. After the time-to-live (ttl) value expires, the name must discard the cached data and obtain new data from the authoritative name s NS name records. The NS records provide the names of the name s and the domains for which the domain has authority. The domain for the name s in the example db.div file is the current origin (div.inc.com) was the last domain specified. A 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. HINFO CNAME 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 looks up a name and finds a CNAME record, the name replaces the name with the canonical name and looks up the new name. B-11

112 DNS Server Configuration Master Server db.domain Files WKS 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 entry 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 for each protocol for each address. MX 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 more than one mail exchanger exists 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. $TTL Indicates (in seconds) the time-to-live (ttl) value for records that do not have the ttl value defined in the data field. B-12

113 Glossary Advanced Research Projects Agency (ARPA). An agency of the United States Department of Defense, ARPA underwrote the development of the Internet beginning in Known as ARPANET, it was designed so that, in case of war and the loss of any group of sites, remaining sites would still be able to communicate along alternate routes. No site would be critical to the operation of the network. Eventually, ARPANET was divided into Milnet, which connected military sites, and a new ARPANET that connected other sites, mainly universities. A new communication protocol was developed, TCP/IP, so that all sites on either of the networks could communicate. ARPA. See Advanced Research Projects Agency (ARPA). Berkeley Internet Name Domain (BIND). An implementation of the DNS protocols that provides an openly redistributable reference implementation of the major components of the DNS, including the named process, the DNS resolver library, and tools for verifying the proper operation of the DNS. The BIND DNS Server is used on the vast majority of name-serving machines on the Internet, providing a robust and stable architecture on top of which an organization's naming architecture can be built. BIND. See Berkeley Internet Name Domain (BIND). DNS. See Domain Name System (DNS). Domain Name System (DNS). A system that defines a hierarchical, yet distributed, database of information about hosts on a network. A domain name is a meaningful and easy-to-remember handle for an Internet address. The network administrator configures the DNS with a list of hostnames and Internet protocol (IP) addresses, allowing users of workstations that are configured to query the DNS to specify remote systems by hostnames rather than by IP addresses. DNS domains should not be confused with Windows NT networking domains. glue records. When an Address record (A record) is used to provide the IP address of a name that does not belong to the current domain, the A record is also called a glue record. Guardian. An environment available for interactive or programmatic use with the HP NonStop operating system. Processes that run in the Guardian environment usually use the Guardian system procedure calls as their application program interface. Interactive users of the Guardian environment usually use the HP Tandem Advanced Command Language (TACL) or another HP product s command interpreter. Contrast with Open System Services (OSS). Incremental Zone Transfer (IXFR). A protocol enhancement to full zone transfer mechanism (AXFR) that transfers only the changed portion of a zone instead of transfering the entire zone file. Glossary-1

114 Glossary Internet protocol (IP) Internet protocol (IP). A data communications protocol that handles the routing of data through a network, which typically consists of many different subnetworks. IP is connectionless. It routes data from a source address to a destination address. Internet protocol version 4 (IPv4). The most widely deployed version of the Internet protocol. IPv4 provides some basic traffic classification mechanisms with its IP Precedence/CBQ and Type of Service header fields. However, network hardware and software have not been configured to use them. Internet protocol version 6 (IPv6). An update to the Internet protocol version 4 (IPv4). Most of the updates concentrate on basics such as expanding the IP address numbering scheme to accommodate the growth of the Internet. However, IPv6 does include a Class header field that is explicitly intended to designate a Class of Service (CoS), which is an extension of IPv4 s IP Precedence/CBQ field. Internet Systems Consortium (ISC). A nonprofit public benefit corporation dedicated to supporting the infrastructure of the universal connected self-organizing Internet and the autonomy of its participants by developing and maintaining core production quality software, protocols, and operations. The BIND 9 Administrator Reference Manual is located on the ISC web site ( IP. See Internet protocol (IP). IPv4. See Internet protocol version 4 (IPv4). IPv6. See Internet protocol version 6 (IPv6). ISC. See Internet Systems Consortium (ISC). IXFR. See Incremental Zone Transfer (IXFR). named.conf file. The main configuration file of the name that contains parameters and references to other data files containing the host information. named process. A demon that is the core process of DNS. The named process requires a configuration file (named.conf) which tells where to load the zone files from. OpenSSL. A toolkit containing implementations of Secure Socket Layer (SSL), Transport Layer Security, and Cryptographic algorithms. Open System Services (OSS). An open system environment available for interactive or programmatic use with the HP NonStop operating system. Processes that run in the OSS environment usually use the OSS application program interface. Interactive users of the OSS environment usually use the OSS shell for their command interpreter. Synonymous with Open System Services (OSS) environment. Contrast with Guardian. OSS. See Open System Services (OSS). Primary Name Server. A name that reads the zone data from a file on its host. Glossary-2

115 Glossary Request for Comment (RFC) Request for Comment (RFC). A formal document from the Internet Engineering Task Force (IETF) that is the result of committee drafting and subsequent review by interested parties. Some RFCs are informational in nature. Of those that are intended to become Internet standards, the final version of the RFC becomes the standard and no further comments or changes are permitted. Change can occur, however, through subsequent RFCs that supersede or elaborate on all or parts of previous RFCs. resolv.conf file. A file that contains details about the address of the name to contact and the domain name to which the name belongs. Resource Record (RR). A DNS data record. RFC. See Request for Comment (RFC). RR. See Resource Record (RR). Simple Network Management Protocol (SNMP). An asynchronous request-response protocol used for network management. SNMP originated as a means for managing TCP/IP and Ethernet networks. Open System Management (OSM) packages can include an SNMP-compliant interface for communication between the system console and HP NonStop s. SNMP. See Simple Network Management Protocol (SNMP). TCP. See Transmission Control Protocol (TCP). Transmission Control Protocol (TCP). A connection-oriented protocol that provides for the reliable exchange of data between a sending and a receiving system. TCP implements functions corresponding to the Open Systems Interconnection (OSI) reference model Layer 4, the transport layer. zone file. A file on a name that designates a domain name along with all of the domain s associated subdomains, IP addresses, and mail. Parts of a zone file include the A record, CNAME, and MX records. Glossary-3

116 Glossary zone file Glossary-4

117 Index A A record B-11 Abbreviations -xvii Abort command 3-23 Acl statement A-18 Add process command 3-22 B Berkeley Internet Name Domain (BIND) A-1 BIND See Berkeley Internet Name Domain (BIND) BIND 9 Administrator Reference Manual -xi C Categories 5-3 Change notification A-2 Channels 5-3 CNAME record B-11 Command abort 3-23 add process 3-22 kill 1-3 named 1-2, 1-3 start process 3-22 Configuration file list for DNS A-18 rndc 2-8 Configuring named as a persistent process 3-22 Copyright statement for ported software -x D Db.cache, file location 2-4 Dig utility file location 2-4 man pages for 2-3 DNS dependencies 2-2 logging in 5-3 scaling 4-1/4-3 starting 1-2 stopping 1-3 troubleshooting 5-1/5-5 verifying that installed 1-1 DNS files, locating 2-4 DNS name space A-1 DNS security 3-3/3-23 Dnssec-keygen utility file location 2-4 man pages 2-3 Dnssec-signzone utility file location 2-4 man pages 2-3 Domain compared to zone A-2 Domain Name System (DNS) See DNS DUAL mode 1-2 Dynamic DNS update A-3 E Expire Start-of-Authority value B-11 F File named.conf (logging statement in) 5-4 named.conf (sample) 5-2 resolv.conf 3-23 Index-1

118 Index G G Gethostbyname2 library call, man pages 2-3 I Include statement A-18 INET6 mode 1-2 K Key statement A-18 Key, shared secret 2-9 Kill command 1-3 L Lightweight Resolver daemon A-4 Library A-4 Locating DNS files 2-4 Logging in DNS Logging statement A-18 lwresd (lightweight resolver demon) file location 2-4 man pages 2-3 lwres_freeaddrinfo library call man pages 2-3 migration to 3-2 lwres_freehostent library call man pages 2-3 migration to 3-3 lwres_gai_strerror library call man pages 2-3 migration to 3-2 lwres_getaddrinfo library call man pages 2-3 migration to 3-2 lwres_gethostbyaddr library call man pages 2-3 migration to 3-2 lwres_gethostbyname library call man pages 2-3 migration to 3-2 lwres_gethostbyname2 library call man pages 2-3 migration to 3-2 lwres_getipnodebyaddr library call man pages 2-3 migration to 3-3 lwres_getipnodebyname library call man pages 2-3 migration to 3-3 lwres_getnameinfo library call man pages 2-3 migration to 3-2 lwres_hstrerror library call man pages 2-3 migration to 3-2 lwres_h_errno library call, migration to 3-3 M Man pages, accessing 2-3 Managing persistence 3-22 Master s and Notify A-2 Migrating the configuration file 2-12 Minimum ttl Start-of-Authority value B-11 MX record B-12 N Name Server 5-4 Name overview A-3 Name space A-1 Named command 1-2, 1-3 Named configuration file statements A-18 Named process (nonsecure) file location 2-4 man pages 2-3 Index-2

119 Index O Named process (secure) file location 2-4 man pages 2-3 Named-bootconf.sh 2-4 Named.conf file file location 2-4 man pages 2-3 Notation conventions -xiii Notify A-2 Nsupdate utility 2-4 man pages (secure) 2-3 man pages, (nonsecure) 2-3 O Options statement A-19 Organization of manual -ix OSS operating system 1-1 OSS organization of DNS files 2-4 P Product ID, nonsecure DNS 2-3 Product ID, secure DNS 2-3 Product number 2-1 Putenv() procedure 3-23 R Refresh Start-of-Authority value B-11 Related manuals -x Resolver how it works A-7 overview A-3 Resolv.conf file man pages 2-3 specifying 3-23 Retry Start-of-Authority value B-11 rndc utility commands 2-7 file location (secure) 2-4 rndc utility (continued) generating the configuration file for 2-8 man pages (nonsecure) 2-3 man pages (secure) 2-3 overview 2-7 syntax 2-7 rndc.conf file location 2-4 S Sample named.conf file 5-2 Scalability for DNS 4-1/4-3 Security 3-3/3-23 Serial Start-of-Authority value B-11 Server statement A-19 Slave s, and Notify A-2 SOA See Start of Authority (SOA) record Sortlist statement A-19 Specifying a different resolv.conf file 3-23 Specifying a TCP/IP process by using a runtime option 3-23 Start of Authority (SOA) record A-2, B-10 Start process command 3-22 Starting DNS 1-2 Starting the named process 3-22 Statement for ported software and related documentation -x Stderr, starting named with 5-1 Stopping DNS 1-3 Stopping named as a persistent process 3-23 Super ID 1-2 T T0685, product number 2-1 T0708, product number 2-1 TCPIP_RESOLVER_NAME variable 3-23 Tools 2-4 Troubleshooting DNS 5-1/5-5 Index-3

120 Index U U Utilities 2-4 V View statement A-19 W WKS record B-12 Z Zone entry 2-5 Zone file 2-12 Zone file sample location 2-4 Zone statement A-19 Zone, compared to domain A-2 Special Characters $ZTC $ZZKRN 2-2, c option, with named command 1-2 -g option 5-1 -t option 3-23 Index-4