From: Andreas Gustafsson Date: Wed, 18 Oct 2000 18:50:18 +0000 (+0000) Subject: remove plain text version of ARM until we find a way to generate X-Git-Tag: v9.0.1rc1~26 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=01b637bd8bee945e46ad96c61ab422ec30d98996;p=thirdparty%2Fbind9.git remove plain text version of ARM until we find a way to generate it from XML --- diff --git a/doc/arm/Bv9ARM.txt b/doc/arm/Bv9ARM.txt deleted file mode 100644 index 1bd12d80ef6..00000000000 --- a/doc/arm/Bv9ARM.txt +++ /dev/null @@ -1,4056 +0,0 @@ -Copyright (C) 2000 Internet Software Consortium. -See COPYRIGHT in the source root or http://isc.org/copyright.html for terms. - -$Id: Bv9ARM.txt,v 1.3.2.7 2000/09/18 17:02:13 gson Exp $ - -BIND 9 Administrator Reference Manual -July 2000 -Copyright (c) 2000 Internet Software Consortium - --------------------------------------------------------------------- - - - BIND 9 ADMINISTRATOR REFERENCE MANUAL - -Table of Contents - -Section 1 : Introduction - -1.1 Scope of Document -1.2 Organization of This Document -1.3 Conventions Used in This Document -1.4 Discussion of Domain Name System (DNS) Basics and BIND -1.4.1 Nameservers -1.4.2 Types of Zones -1.4.3 Servers -1.4.3.1 Master Server -1.4.3.2 Slave Server -1.4.3.3 Caching Only Server -1.4.3.4 Forwarding Server -1.4.3.5 Stealth Server - -Section 2 : BIND Resource Requirements - -2.1 Hardware requirements -2.2 CPU Requirements -2.3 Memory Requirements -2.4 Nameserver Intensive Environment Issues -2.5 Supported Operating Systems - -Section 3 : Nameserver Configuration - -3.1 Sample Configurations -3.1.1 A Caching-only Nameserver -3.1.2 An Authoritative-only Nameserver -3.2 Load Balancing -3.3 Notify -3.4 Nameserver Operations -3.4.1 Tools for Use With the Nameserver Daemon -3.4.1.1 Diagnostic Tools -3.4.1.2 Administrative Tools -3.4.2 Signals - -Section 4 : Advanced Concepts - -4.1 Dynamic Update -4.2 Incremental Zone Transfers (IXFR) -4.3 Split DNS -4.4 TSIG -4.4.1 Generate Shared Keys for Each Pair of Hosts -4.4.1.1 Automatic Generation -4.4.1.2 Manual Generation -4.4.2 Copying the Shared Secret to Both Machines -4.4.3 Informing the Servers of the Key's Existence -4.4.4 Instructing the Server to Use the Key -4.4.5 TSIG Key Based Access Control -4.4.6 Errors -4.5 TKEY -4.6 SIG(0) -4.7 DNSSEC -4.7.1 Generating Keys -4.7.2 Creating a Keyset -4.7.3 Signing the Child's Keyset -4.7.4 Signing the Zone -4.7.5 Configuring Servers -4.8 IPv6 Support in BIND 9 -4.8.1 Address Lookups Using AAAA Records -4.8.2 Address Lookups Using A6 Records -4.8.2.1 A6 Chains -4.8.2.2 A6 Records for DNS Servers -4.8.3 Address to Name Lookups Using Nibble Format -4.8.4 Address to Name Lookups Using Bitstring Format -4.8.5 Using DNAME for Delegation of IPv6 Reverse Addresses - -Section 5 : The BIND 9 Lightweight Resolver - -5.1 The Lightweight Resolver Library -5.2 Running a Resolver Daemon - -Section 6 : BIND 9 Configuration Reference - -6.1 Configuration File Element -6.1.1 Address Match Lists -6.1.1.1 Syntax -6.1.1.2 Definition and Usage -6.1.2 Comment Syntax -6.1.2.1 Syntax -6.1.2.2 Definition and Usage -6.2 Configuration File Grammar -6.2.1 acl Statement Grammar -6.2.2 acl Statement Definition and Usage -6.2.3 controls Statement Grammar -6.2.4 controls Statement Definition and Usage -6.2.5 include Statement Grammar -6.2.6 include Statement Definition and Usage -6.2.7 key Statement Grammar -6.2.8 key Statement Definition and Usage -6.2.9 logging Statement Grammar -6.2.10 logging Statement Definition and Usage -6.2.10.1 The channel Phrase -6.2.10.2 The category Phrase -6.2.11 options Statement Grammar -6.2.12 options Statement Definition and Usage -6.2.12.1 Boolean Options -6.2.12.2 Forwarding -6.2.12.3 Name Checking -6.2.12.4 Access Control -6.2.12.5 Interfaces -6.2.12.6 Query Address -6.2.12.7 Zone Transfers -6.2.12.8 Resource Limits -6.2.12.9 Periodic Task Intervals -6.2.12.10 Topology -6.2.12.11 The sortlist Statement -6.2.12.12 RRset Ordering -6.2.12.13 Tuning -6.2.12.14 Deprecated Features -6.2.13 server Statement Grammar -6.2.14 server Statement Definition and Usage -6.2.15 trusted-keys Statement Grammar -6.2.16 trusted-keys Statement Definition and Usage -6.2.17 view Statement Grammar -6.2.18 view Statement Definition and Usage -6.2.19 zone Statement Grammar -6.2.20 zone Statement Definition and Usage -6.2.20.1 Zone Types -6.2.20.2 Class -6.2.20.3 Zone Options -6.2.20.4 Dynamic Update Policies -6.3 Zone File -6.3.1 Types of Resource Records and When to Use Them -6.3.1.1 Resource Records -6.3.1.2 Textual expression of RRs -6.3.2 Discussion of MX Records -6.3.3 Setting TTLs -6.3.4 Inverse Mapping in IPv4 -6.3.5 Other Zone File Directives -6.3.5.1 The $ORIGIN Directive -6.3.5.2 The $INCLUDE Directive -6.3.5.3 The $TTL Directive -6.3.6 BIND Master File Extension: the $GENERATE Directive -6.3.7 Signals 69 - -Section 7 : BIND 9 Security Considerations - -7.1 Access Control Lists -7.2 chroot and setuid (for UNIX servers) -7.2.1 The chroot Environment -7.2.2 Using the setuid Function -7.3 Dynamic Updates - -Section 8 : Troubleshooting - -8.1 Common Problems -8.1.1 It's not working; how can I figure out what's wrong? -8.2 Incrementing and Changing the Serial Number -8.3 Where Can I Get Help? - -Appendix A: Acknowledgements - -A.1 A Brief History of the DNS and BIND - -Appendix B: Historical DNS Information - -B.1 Classes of Resource Records -B.1.1 HS = hesiod -B.1.2 CH = chaos - -Appendix C: General DNS Reference Information - -C.1 IPv6 addresses (A6) - -Appendix D: Bibliography (and Suggested Reading) - -D.1 Request for Comments (RFCs) -D.1.1 Standards -D.1.2 Proposed Standards -D.1.3 Proposed Standards Still Under Development -D.1.4 Other Important RFCs About DNS Implementation -D.1.5 Resource Record Types -D.1.6 DNS and the Internet -D.1.7 DNS Operations -D.1.8 Other DNS-related RFCs -D.1.9 Obsolete and Unimplemented Experimental RRs -D.2 Internet Drafts -D.3 Other BIND Documents - --------------------------------------------------------------------- - - - - - Section 1. Introduction - -The Internet Domain Name System (DNS) consists of the syntax to specify the -names of entities in the Internet in a hierarchical manner, the rules used -for delegating authority over names, and the system implementation that -actually maps names to Internet addresses. DNS data is maintained in a group -of distributed hierarchical databases. - - 1.1 Scope of Document - -The Berkeley Internet Name Domain (BIND) implements an Internet nameserver -for a number of operating systems. This document provides basic information -about the installation and care of the Internet Software Consortium (ISC) -BIND version 9 software package for system administrators. - - 1.2 Organization of This Document - -In this document, Section 1 introduces the basic DNS and BIND concepts. -Section 2 describes resource requirements for running BIND in various -environments. Information in Section 3 is task-oriented in its presentation -and is organized functionally, to aid in the process of installing the -BIND 9 software. The task-oriented section is followed by Section 4, which -contains more advanced concepts that the system administrator may need for -implementing certain options. Section 5 describes the BIND 9 lightweight -resolver. The contents of Section 6 are organized as in a reference manual -to aid in the ongoing maintenance of the software. Section 7 addresses -security considerations, and Section 8 contains troubleshooting help. The -main body of the document is followed by several Appendices which contain -useful reference information, such as a Bibliography and historic -information related to BIND and the Domain Name System. - - 1.3 Conventions Used in This Document - -In this document, we use the following general typographic conventions: - - To describe: We use the style: - a pathname, filename, URL, hostname, - mailing list name, or new term or conceptItalic - literal user input Fixed Width Bold - variable user input Fixed Width Italic - program output Fixed Width - -The following conventions are used in descriptions of the BIND configuration -file: - - To describe: We use the style: - keywords Sans Serif Bold - - variables Sans Serif Italic - - "meta-syntactic" information (within brackets - when optional) Fixed Width Italic - Command line input Fixed Width Bold - Program output Fixed Width - - Optional input Text is enclosed in square - brackets - - 1.4 Discussion of Domain Name System (DNS) Basics and BIND - -The purpose of this document is to explain the installation and basic upkeep -of the BIND software package, and we begin by reviewing the fundamentals of -the domain naming system as they relate to BIND. BIND consists of a -nameserver (or "daemon") called named and a resolver library. The BIND -server runs in the background, servicing queries on a well known network -port. The standard port for the User Datagram Protocol (UDP) and -Transmission Control Protocol (TCP), usually port 53, is specified in -/etc/services. The resolver is a set of routines residing in a system -library that provides the interface that programs can use to access the -domain name services. - - 1.4.1 Nameservers - -A nameserver (NS) is a program that stores information about named resources -and responds to queries from programs called resolvers which act as client -processes. The basic function of an NS is to provide information about -network objects by answering queries. - -With the nameserver, the network can be broken into a hierarchy of domains. -The name space is organized as a tree according to organizational or -administrative boundaries. Each node of the tree, called a domain, is given -a label. The name of the domain is the concatenation of all the labels of -the domains from the root to the current domain. This is represented in -written form as a string of labels listed from right to left and separated -by dots. A label need only be unique within its domain. The whole name space -is partitioned into areas called zones, each starting at a domain and -extending down to the leaf domains or to domains where other zones start. -Zones usually represent administrative boundaries. For example, a domain -name for a host at the company Example, Inc. would be: - -ourhost.example.com - -where com is the top level domain to which ourhost.example.com belongs, -example is a subdomain of com, and ourhost is the name of the host. - -The specifications for the domain nameserver are defined in the RFC -1034, RFC 1035 and RFC 974. These documents can be found in -/usr/src/etc/named/doc in 4.4BSD or are available via File Transfer -Protocol (FTP) from ftp://www.isi.edu/in-notes/ or via the Web at -http://www.ietf.org/rfc/. (See Appendix C for complete information -on finding and retrieving RFCs.) It is also recommended that you read -the related man pages: named and resolver. - - 1.4.2 Types of Zones - -As we stated previously, a zone is a point of delegation in the DNS tree. A -zone consists of those contiguous parts of the domain tree for which a -domain server has complete information and over which it has authority. It -contains all domain names from a certain point downward in the domain tree -except those which are delegated to other zones. A delegation point has one -or more NS records in the parent zone, which should be matched by equivalent -NS records at the root of the delegated zone. - -To properly operate a nameserver, it is important to understand the -difference between a zone and a domain. - -For instance, consider the example.com domain which includes names such as -host.aaa.example.com and host.bbb.example.com even though the example.com -zone includes only delegations for the aaa.example.com and bbb.example.com -zones. A zone can map exactly to a single domain, but could also include -only part of a domain, the rest of which could be delegated to other -nameservers. Every name in the DNS tree is a domain, even if it is terminal -, that is, has no subdomains. Every subdomain is a domain and every domain -except the root is also a subdomain. The terminology is not intuitive and we -suggest that you read RFCs 1033, 1034 and 1035 to gain a complete -understanding of this difficult and subtle topic. - -Though BIND is a Domain Nameserver, it deals primarily in terms of zones. -The master and slave declarations in the named.conf file specify zones, not -domains. When you ask some other site if it is willing to be a slave server -for your domain, you are actually asking for slave service for some -collection of zones. - -Each zone will have one primary master (also called primary) server which -loads the zone contents from some local file edited by humans or perhaps -generated mechanically from some other local file which is edited by humans. -There there will be some number of slave (also called secondary) servers, -which load the zone contents using the DNS protocol (that is, the secondary -servers will contact the primary and fetch the zone data using TCP). This -set of servers--the primary and all of its secondaries--should be listed in -the NS records in the parent zone and will constitute a delegation. This -set of servers must also be listed in the zone file itself, usually under -the @ name which indicates the top level or root of the current zone. You -can list servers in the zone's top-level @ NS records that are not in the -parent's NS delegation, but you cannot list servers in the parent's -delegation that are not present in the zone's @. - -Any servers listed in the NS records must be configured as authoritative for -the zone. A server is authoritative for a zone when it has been configured -to answer questions for that zone with authority, which it does by setting -the "authoritative answer" (AA) bit in reply packets. A server may be -authoritative for more than one zone. The authoritative data for a zone is -composed of all of the Resource Records (RRs)--the data associated with -names in a tree-structured name space--attached to all of the nodes from the -top node of the zone down to leaf nodes or nodes above cuts around the -bottom edge of the zone. - -Adding a zone as a type master or type slave will tell the server to answer -questions for the zone authoritatively. If the server is able to load the -zone into memory without any errors it will set the AA bit when it replies -to queries for the zone. See RFCs 1034 and 1035 for more information about -the AA bit. - - 1.4.3 Servers - -A DNS server can be master for some zones and slave for others or can be -only a master, or only a slave, or can serve no zones and just answer -queries via its cache. Master servers are often also called primaries and -slave servers are often also called secondaries. Both master/primary and -slave/secondary servers are authoritative for a zone. - -All servers keep data in their cache until the data expires, based on a Time -To Live (TTL) field which is maintained for all resource records. - - 1.4.3.1 Master Server - -The primary master server is the ultimate source of information about a -domain. The primary master is an authoritative server configured to be the -source of zone transfer for one or more secondary servers. The primary -master server obtains data for the zone from a file on disk. - - 1.4.3.2 Slave Server - -A slave server, also called a secondary server, is an authoritative server -that uses zone transfers from the primary master server to retrieve the zone -data. Optionally, the slave server obtains zone data from a cache on disk. -Slave servers provide necessary redundancy. All secondary/slave servers are -named in the NS RRs for the zone. - - 1.4.3.3 Caching Only Server - -Some servers are caching only servers. This means that the server caches -the information that it receives and uses it until the data expires. A -caching only server is a server that is not authoritative for any zone. This -server services queries and asks other servers, who have the authority, for -the information it needs. - - 1.4.3.4 Forwarding Server - -Instead of interacting with the nameservers for the root and other domains, -a forwarding server always forwards queries it cannot satisfy from its -authoritative data or cache to a fixed list of other servers. The forwarded -queries are also known as recursive queries, the same type as a client -would send to a server. There may be one or more servers forwarded to, and -they are queried in turn until the list is exhausted or an answer is found. -A forwarding server is typically used when you do not wish all the servers -at a given site to interact with the rest of the Internet servers. A typical -scenario would involve a number of internal DNS servers and an Internet -firewall. Servers unable to pass packets through the firewall would forward -to the server that can do it, and that server would query the Internet DNS -servers on the internal server's behalf. An added benefit of using the -forwarding feature is that the central machine develops a much more complete -cache of information that all the workstations can take advantage of. - -There is no prohibition against declaring a server to be a forwarder even -though it has master and/or slave zones as well; the effect will still be -that anything in the local server's cache or zones will be answered, and -anything else will be forwarded using the forwarders list. - - 1.4.3.5 Stealth Server - -A stealth server is a server that answers authoritatively for a zone, but is -not listed in that zone's NS records. Stealth servers can be used as a way -to centralize distribution of a zone, without having to edit the zone on a -remote nameserver. Where the master file for a zone resides on a stealth -server in this way, it is often referred to as a "hidden primary" -configuration. Stealth servers can also be a way to keep a local copy of a -zone for rapid access to the zone's records, even if all "official" -nameservers for the zone are inaccessible. - - ------------------------------------------------------------------------ - - Section 2. BIND Resource Requirements - - 2.1 Hardware requirements - -DNS hardware requirements have traditionally been quite modest. For many -installations, servers that have been pensioned off from active duty have -performed admirably as DNS servers. - -The DNSSEC and IPv6 features of BIND 9 may prove to be quite CPU intensive -however, so organizations that make heavy use of these features may wish to -consider larger systems for these applications. BIND 9 is now fully -multithreaded, allowing full utilization of multiprocessor systems for -installations that need it. - - 2.2 CPU Requirements - -CPU requirements for BIND 9 range from i486-class machines for serving of -static zones without caching, to enterprise-class machines if you intend to -process many dynamic updates and DNSSEC signed zones, serving many thousands -of queries per second. - - 2.3 Memory Requirements - -The memory of the server has to be large enough to fit the cache and zones -loaded off disk. Future releases of BIND 9 will provide methods to limit the -amount of memory used by the cache, at the expense of reducing cache hit -rates and causing more DNS traffic. It is still good practice to have enough -memory to load all zone and cache data into memory--unfortunately, the best -way to determine this for a given installation is to watch the nameserver in -operation. After a few weeks the server process should reach a relatively -stable size where entries are expiring from the cache as fast as they are -being inserted. Ideally, the resource limits should be set higher than this -stable size. - - 2.4 Nameserver Intensive Environment Issues - -For nameserver intensive environments, there are two alternative -configurations that may be used. The first is where clients and any -second-level internal nameservers query a main nameserver, which has enough -memory to build a large cache. This approach minimizes the bandwidth used by -external name lookups. The second alternative is to set up second-level -internal nameservers to make queries independently. In this configuration, -none of the individual machines needs to have as much memory or CPU power as -in the first alternative, but this has the disadvantage of making many more -external queries, as none of the nameservers share their cached data. - - 2.5 Supported Operating Systems - -ISC BIND 9 compiles and runs on the following operating systems: - -IBM AIX 4.3 -Compaq Digital/Tru64 UNIX 4.0D -HP HP-UX 11 -IRIX64 6.5 -Red Hat Linux 6.0, 6.1 -Sun Solaris 2.6, 7, 8 (beta) -FreeBSD 3.4-STABLE -NetBSD-current with "unproven" pthreads - - ------------------------------------------------------------------------ - - Section 3. Nameserver Configuration - -In this section we provide some suggested configurations along with -guidelines for their use. We also address the topic of reasonable option -setting. - - 3.1 Sample Configurations - - 3.1.1 A Caching-only Nameserver - -The following sample configuration is appropriate for a caching-only name -server for use by clients internal to a corporation. All queries from -outside clients are refused. - -// Two corporate subnets we wish to allow queries from. -acl "corpnets" { 192.168.4.0/24; 192.168.7.0/24; }; -options { - directory "/etc/namedb"; // Working directory - pid-file "named.pid"; // Put pid file in working dir - allow-query { "corpnets "; }; -}; -// Root server hints -zone "." { type hint; file "root.hint"; }; -// Provide a reverse mapping for the loopback address 127.0.0.1 -zone "0.0.127.in-addr.arpa" { - type master; - file "localhost.rev"; - notify no; - -}; - - 3.1.2 An Authoritative-only Nameserver - -This sample configuration is for an authoritative-only server that is the -master server for " example.com " and a slave for the subdomain " -eng.example.com ". - -options { - directory "/etc/namedb"; // Working directory - pid-file "named.pid"; // Put pid file in working dir - allow-query { any; }; // This is the default - recursion no; // Do not provide recursive service -}; -// Root server hints -zone "." { type hint; file "root.hint"; }; - -// Provide a reverse mapping for the loopback address 127.0.0.1 - zone "0.0.127.in-addr.arpa" { - type master; - file "localhost.rev"; - notify no; -}; -// We are the master server for example.com -zone "example.com" { - type master; - file "example.com.db"; - // IP addresses of slave servers allowed to transfer example.com - allow-transfer { - 192.168.4.14; - 192.168.5.53; - }; -}; - -// We are a slave server for eng.example.com -zone "eng.example.com" { - type slave; - file "eng.example.com.bk"; - // IP address of eng.example.com master server - masters { 192.168.4.12; }; -}; - - 3.2 Load Balancing - -Primitive load balancing can be achieved in DNS using multiple A records for -one name. - -For example, if you have three WWW servers with network addresses of -10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the following -means that clients will connect to each machine one third of the time: - - - - NameTTL CLASS TYPE Resource Record (RR) Data - www 600 IN A 10.0.0.1 - 600 IN A 10.0.0.2 - 600 IN A 10.0.0.3 - -When a resolver queries for these records, BIND will rotate them and respond -to the query with the records in a different order. In the example above, -clients will randomly receive records in the order 1, 2, 3; 2, 3, 1; and 3, -1, 2. Most clients will use the first record returned and discard the rest. - -For more detail on ordering responses, check the rrset-order substatement in -the options statement under RRset Ordering. This substatement is not -supported in BIND 9, and only the ordering scheme described above is -available. - - 3.3 Notify - -DNS Notify is a mechanism that allows master nameservers to notify their -slave servers of changes to a zone's data. In response to a NOTIFY from a -master server, the slave will check to see that its version of the zone is -the current version and, if not, initiate a transfer. - -DNS Notify is fully documented in RFC 1996. See also the description of the -zone option also-notify under Zone Transfers. More information about notify -can be found under Boolean Options. - - 3.4 Nameserver Operations - - 3.4.1 Tools for Use With the Nameserver Daemon - -There are several indispensable diagnostic, administrative and monitoring -tools available to the system administrator for controlling and debugging -the nameserver daemon. We describe several in this section - - 3.4.1.1 Diagnostic Tools - -dig - -The domain information groper ( dig) is a command line tool that can be -used to gather information from the Domain Name System servers. Dig has two -modes: simple interactive mode for a single query, and batch mode which -executes a query for each in a list of several query lines. All query -options are accessible from the command line. - -Usage - -dig [@server] domain [] [] - [+] [-] [%comment] - -The usual simple use of dig will take the form - -dig @server domain query-type query-class - -For more information and a list of available commands and options, see the -dig man page. - -host - -The host utility provides a simple DNS lookup using a command-line interface -for looking up Internet hostnames. By default, the utility converts between -host names and Internet addresses, but its functionality can be extended -with the use of options. - -Usage - -host [-aCdlrTwv] [-c class] [-N ndots] [-t type] - [-W timeout] [-R retries] hostname [server] - -For more information and a list of available commands and options, see the -host man page. - -nslookup - -nslookup is a program used to query Internet domain nameservers. nslookup -has two modes: interactive and non-interactive. Interactive mode allows the -user to query nameservers for information about various hosts and domains or -to print a list of hosts in a domain. Non-interactive mode is used to print -just the name and requested information for a host or domain. - -Usage - -nslookup [-option ...] [host-to-find | -[server]] - -Interactive mode is entered when no arguments are given (the default -nameserver will be used) or when the first argument is a hyphen ('-') and -the second argument is the host name or Internet address of a nameserver. - -Non-interactive mode is used when the name or Internet address of the host -to be looked up is given as the first argument. The optional second argument -specifies the host name or address of a nameserver. - -The options listed under the "set" command (see the nslookup man page for -details) can be specified in the .nslookuprc file in the user's home -directory if they are listed one per line. Options can also be specified on -the command line if they precede the arguments and are prefixed with a -hyphen. For example, to change the default query type to host information, -and the initial time-out to 10 seconds, type: - -nslookup -query=hinfo -timeout=10 - -For more information and a list of available commands and options, see the -nslookup man page. - -Due to its arcane user interface and frequently inconsistent behavior, we do -not recommend the use of nslookup. Use dig instead. - - 3.4.1.2 Administrative Tools - -Administrative tools play an integral part in the management of a server. - -rndc - -The remote name daemon control (rndc) program allows the system -administrator to control the operation of a nameserver. If you run -rndc without any options it will display a usage message as follows: - -Usage: rndc [-c config] [-s server] [-p port] [-y key] command [command ...] - - command is one of the following for named: - - *status Display ps(1) status of named. - *dumpdb Dump database and cache to /var/tmp/named_dump.db. - reload Reload configuration file and zones. - *stats Dump statistics to /var/tmp/named.stats. - *trace Increment debugging level by one. - *notrace Set debugging level to 0. - *querylog Toggle query logging. - *stop Stop the server. - *restart Restart the server. - - * == not yet implemented - -As noted above, "reload" is the only command available for BIND 9.0.0. -The other commands, and more, are planned to be implemented for future -releases. - -A configuration file is required, since all communication with the -server is authenticated with digital signatures that rely on a shared -secret, and there is no way to provide that secret other than with a -configuration file. The default location for the rndc configuration -file is /etc/rndc.conf, but an alternate location can be specified -with the "-c" option. - -The format of the configuration file is similar to that of named.conf, but -limited to only three statements, the options{}, key{} and server{} -statements. These statements are what associate the secret keys to the -servers with which they are meant to be shared. The order of statements is not -significant. - -The options{} statement has two clauses: default-server and -default-key. default-server takes a host name or address argument and -represents the server that will be contacted if no "-s" option is -provided on the command line. default-key takes the name of the key -as its argument, as defined by a key{} statement. In the future a -default-port clause will be added to specify the port to which rndc -should connect. - -The key{} statement names a key with its string argument. The string is -required by the server to be a valid domain name, though it need not -actually be hierarchical; thus, a string like "rndc_key" is a valid name. -The key{} statement has two clauses: algorithm and secret. While the -configuration parser will accept any string as the argument to algorithm, -currently only the string "hmac-md5" has any meaning. The secret is a -base-64 encoded string, typically generated with either dnssec-keygen or -mmencode. - -The server{} statement uses the key clause to associate a key{}-defined key -with a server. The argument to the server{} statement is a host name or -address (addresses must be double quoted). The argument to the key clause -is the name of key as defined by the key{} statement. A port clause will -be added to a future release to specify the port to which rndc should -connect on the given server. - -A sample minimal configuration file is as follows: - -key rndc_key { - algorithm "hmac-md5"; - secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; -}; - -options { - default-server localhost; - default-key rndc_key; -}; - -This file, if installed as /etc/rndc.conf, would allow the command: - -$ rndc reload - -to connect to 127.0.0.1 port 953 and cause the nameserver to reload, -if a nameserver on the local machine were running with following controls -statements: - -controls { - inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; -}; - -and it had an identical key statement for rndc_key. - - -3.4.2 Signals - -Certain UNIX signals cause the name server to take specific actions, as -described in the following table. These signals can be sent using the kill -command. - - SIGHUP Causes the server to read named.conf and reload the database. - SIGTERM Causes the server to clean up and exit. - SIGINT Causes the server to clean up and exit. - - - ------------------------------------------------------------------------ - -Section 4. Advanced Concepts - -4.1 Dynamic Update - -Dynamic update is the term used for the ability under certain specified -conditions to add, modify or delete records or RRsets in the master zone -files. Dynamic update is fully described in RFC 2136. - -Dynamic update is enabled on a zone-by-zone basis, by including an -allow-update or update-policy clause in the zone statement. - -Updating of secure zones (zones using DNSSEC) is modelled after the -simple-secure-update proposal, a work in progress in the DNS Extensions -working group of the IETF. (See -http://www.ietf.org/html.charters/dnsext-charter.html for information about -the DNS Extensions working group.) SIG and NXT records affected by updates -are automatically regenerated by the server using an online zone key. Update -authorization is based on transaction signatures and an explicit server -policy. - -The zone files of dynamic zones must not be edited by hand. The zone file on -disk at any given time may not contain the latest changes performed by -dynamic update. The zone file is written to disk only periodically, and -changes that have occurred since the zone file was last written to disk are -stored only in the zone's journal ( .jnl) file. BIND 9 currently does not -update the zone file when it exits as BIND 8 does, so editing the zone file -manually is unsafe even when the server has been shut down. - -4.2 Incremental Zone Transfers (IXFR) - -The incremental zone transfer (IXFR) protocol is a way for slave servers to -transfer only changed data, instead of having to transfer the entire zone. -The IXFR protocol is documented in RFC 1995. See the list of proposed -standards in Appendix C. - -When acting as a master, BIND 9 supports IXFR for those zones where the -necessary change history information is available. These include master -zones maintained by dynamic update and slave zones whose data was obtained -by IXFR, but not manually maintained master zones nor slave zones obtained -by performing a full zone transfer (AXFR). - -When acting as a slave, BIND 9 will attempt to use IXFR unless it is -explicitly disabled. For more information about disabling IXFR, see the -description of the request-ixfr clause of the server statement. - -4.3 Split DNS - -Setting up different views, or visibility, of DNS space to internal and -external resolvers is usually referred to as a Split DNS setup. There are -several reasons an organization would want to set up its DNS this way. - -One common reason for setting up a DNS system this way is to hide "internal" -DNS information from "external" clients on the Internet. There is some -debate as to whether or not this is actually useful. Internal DNS -information leaks out in many ways (via email headers, for example) and most -savvy "attackers" can find the information they need using other means. - -Another common reason for setting up a Split DNS system is to allow internal -networks that are behind filters or in RFC 1918 space (reserved IP space, as -documented in RFC 1918) to resolve DNS on the Internet. Split DNS can also -be used to allow mail from outside back in to the internal network. - -Here is an example of a split DNS setup: - -Let's say a company named Example, Inc. (example.com) has several corporate -sites that have an internal network with reserved Internet Protocol (IP) -space and an external demilitarized zone (DMZ), or "outside" section of a -network, that is available to the public. - -Example, Inc. wants its internal clients to be able to resolve external -hostnames and to exchange mail with people on the outside. The company also -wants its internal resolvers to have access to certain internal-only zones -that are not available at all outside of the internal network. - -In order to accomplish this, the company will set up two sets of -nameservers. One set will be on the inside network (in the reserved IP -space) and the other set will be on bastion hosts, which are "proxy" hosts -that can talk to both sides of its network, in the DMZ. - -The internal servers will be configured to forward all queries, except -queries for site1.internal, site2.internal, site1.example.com, and -site2.example.com, to the servers in the DMZ. These internal servers -will have complete sets of information for site1.example.com, -site2.example.com, site1.internal, and site2.internal. - -To protect the site1.internal and site2.internal domains, the internal -nameservers must be configured to disallow all queries to these -domains from any external hosts, including the bastion hosts. - -The external servers, which are on the bastion hosts, will be -configured to serve the "public" version of the site1 and -site2.example.com zones. This could include things such as the host -records for public servers (www.example.com and ftp.example.com), and -mail exchange (MX) records (a.mx.example.com and b.mx.example.com). - -In addition, the public site1 and site2.example.com zones should have -special MX records that contain wildcard ('*') records pointing to the -bastion hosts. This is needed because external mail servers do not have any -other way of looking up how to deliver mail to those internal hosts. With -the wildcard records, the mail will be delivered to the bastion host, which -can then forward it on to internal hosts. - -Here's an example of a wildcard MX record: - -* IN MX 10 external1.example.com. - -Now that they accept mail on behalf of anything in the internal network, the -bastion hosts will need to know how to deliver mail to internal hosts. In -order for this to work properly, the resolvers on the bastion hosts will -need to be configured to point to the internal nameservers for DNS -resolution. - -Queries for internal hostnames will be answered by the internal servers, and -queries for external hostnames will be forwarded back out to the DNS servers -on the bastion hosts. - -In order for all this to work properly, internal clients will need to be -configured to query only the internal nameservers for DNS queries. This -could also be enforced via selective filtering on the network. - -If everything has been set properly, Example, Inc.'s internal clients will -now be able to: - - * Look up any hostnames in the site1 and site2.example.com zones. - * Look up any hostnames in the site1.internal and site2.internal domains. - * Look up any hostnames on the Internet. - * Exchange mail with internal AND external people. - -Hosts on the Internet will be able to: - - * Look up any hostnames in the site1 and site2.example.com zones. - * Exchange mail with anyone in the site1 and site2.example.com zones. - -Here is an example configuration for the setup we just described above. Note -that this is only configuration information; for information on how to -configure your zone files, see the Sample Configurations. - -Internal DNS server config: - -acl internals { 172.16.72.0/24; 192.168.1.0/24; }; -acl externals { bastion-ips-go-here; }; -options { - ... - ... - forward only; - forwarders { bastion-ips-go-here; }; // forward to external servers - allow-transfer { none; }; // sample allow-transfer (no one) - allow-query { internal; externals; }; // restrict query access - allow-recursion { internals; }; // restrict recursion - ... - ... -}; - -zone "site1.example.com" { // sample slave zone - type master; - file "m/site1.example.com"; - forwarders { }; // do normal iterative - // resolution (do not forward) - allow-query { internals; externals; }; - allow-transfer { internals; }; - }; - -zone "site2.example.com" { - type slave; - file "s/site2.example.com"; - masters { 172.16.72.3; }; - forwarders { }; - allow-query { internals; externals; }; - allow-transfer { internals; }; -}; - -zone "site1.internal" { - type master; - file "m/site1.internal"; - forwarders { }; - allow-query { internals; }; - allow-transfer { internals; } -}; - -zone "site2.internal" { - type slave; - file "s/site2.internal"; - masters { 172.16.72.3; }; - forwarders { }; - allow-query { internals }; - allow-transfer { internals; } -}; - -External (bastion host) DNS server config: - -acl internals { 172.16.72.0/24; 192.168.1.0/24; }; -acl externals { -bastion-ips-go-here; }; -options { - ... - ... - allow-transfer { none; }; // sample allow-transfer (no one) - allow-query { internals; externals; }; // restrict query access - allow-recursion { internals; externals; }; // restrict recursion - ... - ... -}; - -zone "site1.example.com" { // sample slave zone - type master; - file "m/site1.foo.com"; - allow-query { any; }; - allow-transfer { internals; externals; }; -}; - -zone "site2.example.com" { - type slave; - file "s/site2.foo.com"; - masters { another_bastion_host_maybe; }; - allow-query { any; }; - allow-transfer { internals; externals; } -}; - -In the resolv.conf (or equivalent) on the bastion host(s): - -search ... -nameserver 172.16.72.2 -nameserver 172.16.72.3 -nameserver 172.16.72.4 - -4.4 TSIG - -This is a short guide to setting up Transaction SIGnatures (TSIG) based -transaction security in BIND. It describes changes to the configuration file -as well as what changes are required for different features, including the -process of creating transaction keys and using transaction signatures with -BIND. - -BIND primarily supports TSIG for server to server communication. This -includes zone transfer, notify, and recursive query messages. Resolvers -based on newer versions of BIND 8 have limited support for TSIG. - -TSIG might be most useful for dynamic update. A primary server for a -dynamic zone should use access control to control updates, but -IP-based access control is insufficient. Key-based access control is -far superior. See RFC 2845 in the Proposed Standards section of the -Appendix. The nsupdate program supports TSIG via the " -k " and "-y" -command line options. - -4.4.1 Generate Shared Keys for Each Pair of Hosts - -A shared secret is generated to be shared between host1 and host2. An -arbitrary key name is chosen: "host1-host2.". The key name must be the same -on both hosts. - -4.4.1.1 Automatic Generation - -The following command will generate a 128 bit (16 byte) HMAC-MD5 key as -described above. Longer keys are better, but shorter keys are easier to -read. Note that the maximum key length is 512 bits; keys longer than that -will be digested with MD5 to produce a 128 bit key. - -dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2. - -The key is in the file Khost1-host2.+157+00000.private. Nothing directly -uses this file, but the base-64 encoded string following " Key :" can be -extracted from the file and used as a shared secret: - -Key: La/E5CjG9O+os1jq0a2jdA== - -The string " La/E5CjG9O+os1jq0a2jdA== " can be used as the shared secret. - -4.4.1.2 Manual Generation - -The shared secret is simply a random sequence of bits, encoded in base-64. -Most ASCII strings are valid base-64 strings (assuming the length is a -multiple of 4 and only valid characters are used), so the shared secret can -be manually generated. - -Also, a known string can be run through mmencode or a similar program to -generate base-64 encoded data. - -4.4.2 Copying the Shared Secret to Both Machines - -This is beyond the scope of DNS. A secure transport mechanism should be -used. This could be secure FTP, ssh, telephone, etc. - -4.4.3 Informing the Servers of the Key's Existence - -Imagine host1 and host 2 are both servers. The following is added to each -server's named.conf file: - -key host1-host2. { - algorithm hmac-md5; - secret "La/E5CjG9O+os1jq0a2jdA=="; -}; - -The algorithm, hmac-md5, is the only one supported by BIND. The secret is -the one generated above. Since this is a secret, it is recommended that -either named.conf be non-world readable, or the key directive be added to a -non-world readable file that is included by named.conf. - -At this point, the key is recognized. This means that if the server receives -a message signed by this key, it can verify the signature. If the signature -succeeds, the response is signed by the same key. - -4.4.4 Instructing the Server to Use the Key - -Since keys are shared between two hosts only, the server must be told -when keys are to be used. The following is added to the named.conf -file for host1, if the IP address of host2 is 10.1.2.3: - -server 10.1.2.3 { - keys { host1-host2. ;}; -}; - -Multiple keys may be present, but only the first is used. This directive -does not contain any secrets, so it may be in a world-readable file. - -If host1 sends a message that is a response to that address, the message -will be signed with the specified key. host1 will expect any responses to -signed messages to be signed with the same key. - -A similar statement must be present in host2's configuration file (with -host1's address) for host2 to sign non-response messages to host1. - -4.4.5 TSIG Key Based Access Control - -BIND allows IP addresses and ranges to be specified in ACL definitions and -allow-{ query | transfer | update } directives. This has been extended to -allow TSIG keys also. The above key would be denoted key host1-host2. - -An example of an allow-update directive would be: - -allow-update { key host1-host2. ;}; - -This allows dynamic updates to succeed only if the request was signed by a -key named " host1-host2. ". - -The more powerful update-policy statement is described Dynamic Update -Policies. - -4.4.6 Errors - -The processing of TSIG signed messages can result in several errors. If a -signed message is sent to a non-TSIG aware server, a FORMERR will be -returned, since the server will not understand the record. This is a result -of misconfiguration, since the server must be explicitly configured to send -a TSIG signed message to a specific server. - -If a TSIG aware server receives a message signed by an unknown key, the -response will be unsigned with the TSIG extended error code set to BADKEY. -If a TSIG aware server receives a message with a signature that does not -validate, the response will be unsigned with the TSIG extended error code -set to BADSIG. If a TSIG aware server receives a message with a time outside -of the allowed range, the response will be signed with the TSIG extended -error code set to BADTIME, and the time values will be adjusted so that the -response can be successfully verified. In any of these cases, the message's -rcode is set to NOTAUTH. - -4.5 TKEY - -TKEY is a mechanism for automatically generating a shared secret between two -hosts. There are several "modes" of TKEY that specify how the key is -generated or assigned. BIND implements only one of these modes, the -Diffie-Hellman key exchange. Both hosts are required to have a -Diffie-Hellman KEY record (although this record is not required to be -present in a zone). The TKEY process must use signed messages, signed either -by TSIG or SIG(0). The result of TKEY is a shared secret that can be used to -sign messages with TSIG. TKEY can also be used to delete shared secrets that -it had previously generated. - -The TKEY process is initiated by a client or server by sending a signed TKEY -query (including any appropriate KEYs) to a TKEY-aware server. The server -response, if it indicates success, will contain a TKEY record and any -appropriate keys. After this exchange, both participants have enough -information to determine the shared secret; the exact process depends on the -TKEY mode. When using the Diffie-Hellman TKEY mode, Diffie-Hellman keys are -exchanged, and the shared secret is derived by both participants. - -4.6 SIG(0) - -BIND 9 partially supports DNSSEC SIG(0) transaction signatures as specified -in RFC 2535. SIG(0) uses public/private keys to authenticate messages. -Access control is performed in the same manner as TSIG keys; privileges can -be granted or denied based on the key name. - -When a SIG(0) signed message is received, it will only be verified if the -key is known and trusted by the server; the server will not attempt to -locate and/or validate the key. - -BIND 9 does not ship with any tools that generate SIG(0) signed messages. - -4.7 DNSSEC - -Cryptographic authentication of DNS information is possible through the DNS -Security ( DNSSEC) extensions, defined in RFC 2535. This section describes -the creation and use of DNSSEC signed zones. - -In order to set up a DNSSEC secure zone, there are a series of steps which -must be followed. BIND 9 ships with several tools that are used in this -process, which are explained in more detail below. In all cases, the " -h " -option prints a full list of parameters. - -There must also be communication with the administrators of the parent -and/or child zone to transmit keys and signatures. A zone's security status -must be indicated by the parent zone for a DNSSEC capable resolver to trust -its data. - -For other servers to trust data in this zone, they must either be statically -configured with this zone's zone key or the zone key of another zone above -this one in the DNS tree. - -4.7.1 Generating Keys - -The dnssec-keygen program is used to generate keys. - -A secure zone must contain one or more zone keys. The zone keys will sign -all other records in the zone, as well as the zone keys of any secure -delegated zones. Zone keys must have the same name as the zone, a name type -of ZONE, and must be usable for authentication. It is recommended that zone -keys be mandatory to implement a cryptographic algorithm; currently the only -key mandatory to implement an algorithm is DSA. - -The following command will generate a 768 bit DSA key for the child.example -zone: - -dnssec-keygen -a DSA -b 768 -n ZONE child.example. - -Two output files will be produced: Kchild.example.+003+12345.key and -Kchild.example.+003+12345.private (where 12345 is an example of a key -tag). The key file names contain the key name ( child.example.), -algorithm (3 is DSA, 1 is RSA, etc.), and the key tag (12345 in this -case). 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. - -To generate another key with the same properties (but with a different key -tag), repeat the above command. - -The public keys should be inserted into the zone file with $INCLUDE -statements, including the .key files. - -4.7.2 Creating a Keyset - -The dnssec-makekeyset program is used to create a key set from one or more -keys. - -Once the zone keys have been generated, a key set must be built for -transmission to the administrator of the parent zone, so that the parent -zone can sign the keys with its own zone key and correctly indicate the -security status of this zone. When building a key set, the list of keys to -be included and the TTL of the set must be specified, and the desired -signature validity period of the parent's signature may also be specified. - -The list of keys to be inserted into the key set may also included non-zone -keys present at the top of the zone. dnssec-makekeyset may also be used at other -names in the zone. - -The following command generates a key set containing the above key and -another key similarly generated, with a TTL of 3600 and a signature validity -period of 10 days starting from now. - -dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 -Kchild.example.+003+23456 - -One output file is produced: child.example.keyset. This file should be -transmitted to the parent to be signed. It includes the keys, as well as -signatures over the key set generated by the zone keys themselves, which are -used to prove ownership of the private keys and encode the desired validity -period. - -4.7.3 Signing the Child's Keyset - -The dnssec-signkey program is used to sign one child's keyset. - -If the child.example zone has any delegations which are secure, for example, -grand.child.example, the child.example administrator should receive keyset -files for each secure subzone. These keys must be signed by this zone's zone -keys. - -The following command signs the child's key set with the zone keys: - -dnssec-signkey grand.child.example.keyset Kchild.example.+003+12345 -Kchild.example.+003+23456 - -One output file is produced: grand.child.example.signedkey. This file -should be both transmitted back to the child and retained. It includes all -keys (the child's keys) from the keyset file and signatures generated by -this zone's zone keys. - -4.7.4 Signing the Zone - -The dnssec-signzone program is used to sign a zone. - -Any signedkey files corresponding to secure subzones should be present, as -well as a signedkey file for this zone generated by the parent (if there is -one). The zone signer will generate NXT and SIG records for the zone, as -well as incorporate the zone key signature from the parent and indicate the -security status at all delegation points. - -The following command signs the zone, assuming it is in a file called -zone.child.example. By default, all zone keys which have an available -private key are used to generate signatures. - -dnssec-signzone -o child.example zone.child.example - -One output file is produced: zone.child.example.signed. This file should be -referenced by named.conf as the input file for the zone. - -4.7.5 Configuring Servers - -Unlike in BIND 8, data is not verified on load in BIND 9, so zone keys for -authoritative zones do not need to be specified in the configuration file. - -The public key for any security root must be present in the configuration -file's -trusted-keys statement, as described later in this document. - -4.8 IPv6 Support in BIND 9 - -BIND 9 fully supports all currently defined forms of IPv6 name to address -and address to name lookups. It will also use IPv6 addresses to make queries -when running on an IPv6 capable system. - -For forward lookups, BIND 9 supports both A6 and AAAA records. The of AAAA -records is deprecated, but it is still useful for hosts to have both AAAA -and A6 records to maintain backward compatibility with installations where -AAAA records are still used. In fact, the stub resolvers currently shipped -with most operating system support only AAAA lookups, because following A6 -chains is much harder than doing A or AAAA lookups. - -For IPv6 reverse lookups, BIND 9 supports the new "bitstring" format used in -the ip6.arpa domain, as well as the older, deprecated "nibble" format used -in the ip6.int domain. - -BIND 9 includes a new lightweight resolver library and resolver daemon which -new applications may choose to use to avoid the complexities of A6 chain -following and bitstring labels. See The BIND 9 Lightweight Resolver for more -information. - -4.8.1 Address Lookups Using AAAA Records - -The AAAA record is a parallel to the IPv4 A record. It specifies the entire -address in a single record. For example, - -$ORIGIN example.com. -host 1h IN AAAA 3ffe:8050:201:1860:42::1 - -While their use is deprecated, they are useful to support older IPv6 -applications. They should not be added where they are not absolutely -necessary. - -4.8.2 Address Lookups Using A6 Records - -The A6 record is more flexible than the AAAA record, and is therefore more -complicated. The A6 record can be used to form a chain of A6 records, each -specifying part of the IPv6 address. It can also be used to specify the -entire record as well. For example, this record supplies the same data as -the AAAA record in the previous example: - -$ORIGIN example.com. -host 1h IN A6 0 3ffe:8050:201:1860:42::1 - -4.8.2.1 A6 Chains - -A6 records are designed to allow network renumbering. This works when an A6 -record only specifies the part of the address space the domain owner -controls. For example, a host may be at a company named "company." It has -two ISPs which provide IPv6 address space for it. These two ISPs fully -specify the IPv6 prefix they supply. - -In the company's address space: - -$ORIGIN example.com. -host 1h IN A6 64 0:0:0:0:42::1 company.example1.net. -host 1h IN A6 64 0:0:0:0:42::1 company.example2.net. - -ISP1 will use: - -$ORIGIN example1.net. -company 1h IN A6 0 3ffe:8050:201:1860:: - -ISP2 will use: - -$ORIGIN example2.net. -company 1h IN A6 0 1234:5678:90ab:fffa:: - -When host.example.com is looked up, the resolver (in the resolver daemon or -caching name server) will find two partial A6 records, and will use the -additional name to find the remainder of the data. - -4.8.2.2 A6 Records for DNS Servers - -When an A6 record specifies the address of a name server, it should use the -full address rather than specifying a partial address. For example: - -$ORIGIN example.com. -@ 4h IN NS ns0 - 4h IN NS ns1 - -ns0 4h IN A6 0 3ffe:8050:201:1860:42::1 -ns1 4h IN A 192.168.42.1 - -It is recommended that IPv4-in-IPv6 mapped addresses not be used. If a host -has an IPv4 address, use an A record, not an A6, with ::ffff:192.168.42.1 as -the address. - -4.8.3 Address to Name Lookups Using Nibble Format - -While the use of nibble format to look up names is deprecated, it is -supported for backwards compatiblity with existing IPv6 applications. - -When looking up an address in nibble format, the address components are -simply reversed, just as in IPv4, and ip6.int. is appended to the resulting -name. For example, the following would provide reverse name lookup for a -host with address 3ffe:8050:201:1860:42::1. - -$ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int. -1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 4h IN PTR host.example.com. - -4.8.4 Address to Name Lookups Using Bitstring Format - -Bitstring labels can start and end on any bit boundary, rather than on a -multiple of 4 bits as in the nibble format. They also use ip6.arpa rather -than ip6.int. - -To replicate the previous example using bitstrings: - -$ORIGIN \[x3ffe805002011860/64].ip6.arpa. -\[x0042000000000001/64] 4h IN PTR host.example.com. - -4.8.5 Using DNAME for Delegation of IPv6 Reverse Addresses - -In IPV6, the same host may have many addresses from many network -providers. Since the trailing portion of the address usually -remains constant, DNAME can help reduce the number of zone files used -for reverse mapping that need to be maintained. - -For example, consider a host which has two providers (example.net and -example2.net) and therefore two IPv6 addresses. Since the host chooses -its own 64 bit host address portion, the provider address is the only -part that changes: - -$ORIGIN example.com. -host A6 64 ::1234:5678:1212:5675 cust1.example.net. - A6 64 ::1234:5678:1212:5675 subnet5.example2.net. - -$ORIGIN example.net. -cust1 A6 48 0:0:0:dddd:: ipv6net.example.net. -ipv6net A6 0 aa:bb:cccc:: - -$ORIGIN example2.net. -subnet5 A6 48 0:0:0:1:: ipv6net2.example2.net. -ipv6net2 A6 0 6666:5555:4:: - - -This sets up forward lookups. To handle the reverse lookups, the -provider example.net would have: - -$ORIGIN \[x00aa00bbcccc/48].ip6.arpa. -\[xdddd/16] DNAME ipv6-rev.example.com. - -and example2.net would have: - -$ORIGIN \[x666655550004/48].ip6.arpa. -\[x0001/16] DNAME ipv6-rev.example.com. - -example.com needs only one zone file to handle both of these reverse -mappings: - -$ORIGIN ipv6-rev.example.com. -\[x1234567812125675/64] PTR host.example.com. - - - ------------------------------------------------------------------------ - - Section 5. The BIND 9 Lightweight Resolver - - 5.1 The Lightweight Resolver Library - -Traditionally applications have been linked with a stub resolver library -that sends recursive DNS queries to a local caching name server. - -IPv6 introduces new complexity into the resolution process, such as -following A6 chains and DNAME records, and simultaneous lookup of IPv4 and -IPv6 addresses. These are hard or impossible to implement in a traditional -stub resolver. - -Instead, BIND 9 provides resolution services to local clients using a -combination of a lightweight resolver library and a resolver daemon process -running on the local host. These communicate using a simple UDP-based -protocol, the "lightweight resolver protocol" that is distinct from and -simpler than the full DNS protocol. - - 5.2 Running a Resolver Daemon - -To use the lightweight resolver interface, the system must run the resolver -daemon lwresd. - -Applications using the lightweight resolver library will make UDP requests -to the IPv4 loopback address (127.0.0.1) on port 921. The daemon will try to -find the answer to the questions "what are the addresses for host -foo.example.com ?" and "what are the names for IPv4 address 204.152.184.79?" - -The daemon currently only looks in the DNS, but in the future it may use -other sources such as /etc/hosts, NIS, etc. - -The lwresd daemon is essentially a stripped-down, caching-only name server -that answers requests using the lightweight resolver protocol rather than -the DNS protocol. Because it needs to run on each host, it is designed to -require no or minimal configuration. It uses the name servers listed on -nameserver lines in /etc/resolv.conf as forwarders, but is also capable of -doing the resolution autonomously if none are specified. - - ------------------------------------------------------------------------ - -Section 6. BIND 9 Configuration Reference - -BIND 9 configuration is broadly similar to BIND 8.x; however, there are a -few new areas of configuration, such as views. BIND 8.x configuration files -should work with few alterations in BIND 9, although more complex -configurations should be reviewed to check if they can be more efficiently -implemented using the new features found in BIND 9. - -BIND 4 configuration files can be converted to the new format using the -shell script -contrib/named-bootconf/named-bootconf.sh. - -6.1 Configuration File Elements - -Following is a list of elements used throughout the BIND configuration file -documentation: - - - - acl_name The name of an address_match_list as defined by the acl - statement. - - address_match_list A list of one or more ip_addr, ip_prefix, key_id, or - acl_name elements, as described in Address Match Lists. - - domain_name A quoted string which will be used as a DNS name, for - example " my.test.domain ". - - dotted_decimal One or more integers valued 0 through 255 separated - only by dots ('.'), such as 123, 45.67 or 89.123.45.67. - - ip4_addr An IPv4 address with exactly four elements in - dotted_decimal notation. - ip6_addr - An IPv6 address, such as fe80::200:f8ff:fe01:9742. - - ip_addr An ip4_addr or ip6_addr. - - ip_port An IP port number. number is limited to 0 through - 65535, with values below 1024 typically restricted to - root-owned processes. In some cases an asterisk ('*') - character can be used as a placeholder to select a - random high-numbered port. - - An IP network specified as an ip_addr, followed by a - ip_prefix slash ('/') and then the number of bits in the netmask. - For example, 127/8 is the network 127.0.0.0 with - netmask 255.0.0.0 and 1.2.3.0/28 is network 1.2.3.0 - with netmask 255.255.255.240. - - key_id A domain_name representing the name of a shared key, to - be used for transaction security. - - key_list A list of one or more key_ids, separated by semicolons - and ending with a semicolon. - - number A non-negative integer with an entire range limited by - the range of a C language signed integer (2,147,483,647 - on a machine with 32 bit integers). Its acceptable - value might further be limited by the context in which - it is used. - - path_name A quoted string which will be used as a pathname, such - as " zones/master/my.test.domain ". - - size_spec A number, the word unlimited, or the word default. - The maximum value of size_spec is that of unsigned long - integers on the machine. An unlimited size_spec - requests unlimited use, or the maximum available - amount. A default size_spec uses the limit that was in - force when the server was started. - A number can optionally be followed by a scaling - factor: K or k for kilobytes, M or m for megabytes, and - G or g for gigabytes, which scale by 1024, 1024*1024, - and 1024*1024*1024 respectively. - Integer storage overflow is currently silently ignored - during conversion of scaled values, resulting in values - less than intended, possibly even negative. Using - unlimited is the best way to safely set a really large - number. - - yes_or_no Either yes or no. The words true and false are also - accepted, as are the numbers 1 and 0. - -6.1.1 Address Match Lists - -6.1.1.1 Syntax - -address_match_list = address_match_list_element ; -[ address_match_list_element; ... ] -address_match_list_element = [ ! ] (ip_address [/length] | -key key_id | acl_name | { address_match_list } ) - -6.1.1.2 Definition and Usage - -Address match lists are primarily used to determine access control for -various server operations. They are also used to define priorities for -querying other nameservers and to set the addresses on which named will -listen for queries. The elements which constitute an address match list can -be any of the following: - - * an IP address (IPv4 or IPv6) - * an IP prefix (in the `/'-notation) - * a key ID, as defined by the key statement - * the name of an address match list previously defined with the acl - statement - * a nested address match list enclosed in braces - -Elements can be negated with a leading exclamation mark ('!') and the match -list names "any," "none," "localhost" and "localnets" are predefined. More -information on those names can be found in the description of the acl -statement. - -The addition of the key clause made the name of this syntactic element -something of a misnomer, since security keys can be used to validate access -without regard to a host or network address. Nonetheless, the term "address -match list" is still used throughout the documentation. - -When a given IP address or prefix is compared to an address match list, the -list is traversed in order until an element matches. The interpretation of a -match depends on whether the list is being used for access control, defining -listen-on ports, or as a topology, and whether the element was negated. - -When used as an access control list, a non-negated match allows access and a -negated match denies access. If there is no match, access is denied. The -clauses allow-query, allow-transfer, allow-update and blackhole all use -address match lists this. Similarly, the listen-on option will cause the -server to not accept queries on any of the machine's addresses which do not -match the list. - -When used with the topology clause, a non-negated match returns a distance -based on its position on the list (the closer the match is to the start of -the list, the shorter the distance is between it and the server). A negated -match will be assigned the maximum distance from the server. If there is no -match, the address will get a distance which is further than any non-negated -list element, and closer than any negated element. - -Because of the first-match aspect of the algorithm, an element that defines -a subset of another element in the list should come before the broader -element, regardless of whether either is negated. For example, in -1.2.3/24; ! 1.2.3.13; the 1.2.3.13 element is completely useless because the -algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 element. Using -! 1.2.3.13; 1.2.3/24 fixes that problem by having 1.2.3.13 blocked by the -negation but all other 1.2.3.* hosts fall through. - -6.1.2 Comment Syntax - -The BIND 9 comment syntax allows for comments to appear anywhere that white -space may appear in a BIND configuration file. To appeal to programmers of -all kinds, they can be written in C, C++, or shell/perl constructs. - -6.1.2.1 Syntax - -/* This is a BIND comment as in C */ -// This is a BIND comment as in C++ -# This is a BIND comment as in common UNIX shells and perl - -6.1.2.2 Definition and Usage - -Comments may appear anywhere that whitespace may appear in a BIND -configuration file. - -C-style comments start with the two characters /* (slash, star) and end with -*/ (star, slash). Because they are completely delimited with these -characters, they can be used to comment only a portion of a line or to span -multiple lines. - -C-style comments cannot be nested. For example, the following is not valid -because the entire comment ends with the first */: - -/* This is the start of a comment. -This is still part of the comment. -/* This is an incorrect attempt at nesting a comment. */ -This is no longer in any comment. */ - -C++-style comments start with the two characters // (slash, slash) and -continue to the end of the physical line. They cannot be continued across -multiple physical lines; to have one logical comment span multiple lines, -each line must use the // pair. - -For example: - -// This is the start of a comment. The next line -// is a new comment, even though it is logically -// part of the previous comment. - -Shell-style (or perl-style, if you prefer) comments start with the character -# (number sign) and continue to the end of the physical line, as in C++ -comments. - -For example: - -# This is the start of a comment. The next line -# is a new comment, even though it is logically -# part of the previous comment. - -WARNING: you cannot use the semicolon (';') character to start a comment -such as you would in a zone file. The semicolon indicates the end of a -configuration statement. - -6.2 Configuration File Grammar - -A BIND 9 configuration consists of statements and comments. Statements end -with a semicolon. Statements and comments are the only elements that can -appear without enclosing braces. Many statements contain a block of -substatements, which are also terminated with a semicolon. - -The following statements are supported: - - acl defines a named IP address matching list, for access control - and other uses. - - controls declares control channels to be used by the rndc utility. - - include includes a file. - - key specifies key information for use in authentication and - authorization using TSIG. - - logging specifies what the server logs, and where the log messages - are sent. - - options controls global server configuration options and sets - defaults for other statements. - - server sets certain configuration options on a per-server basis. - - trusted-keys defines trusted DNSSEC keys. - - view defines a view. - - zone defines a zone. - -The logging and options statements may only occur once per configuration. - -6.2.1 acl Statement Grammar - -acl acl-name { - address_match_list -}; - -6.2.2 acl Statement Definition and Usage - -The acl statement assigns a symbolic name to an address match list. It gets -its name from a primary use of address match lists: Access Control Lists -(ACLs). - -Note that an address match list's name must be defined with acl before it -can be used elsewhere; no forward references are allowed. - -The following ACLs are built-in: - - any Matches all hosts. - none Matches no hosts. - localhost Matches the IP addresses of all interfaces on the system. - - localnets Matches any host on a network for which the system has an - interface. - -6.2.3 controls Statement Grammar - -controls { - [ inet (ip_addr|*) port ip_port allow { address_match_list } ; - keys { key_list }; - [ inet...; ] -}; - -6.2.4 controls Statement Definition and Usage - -The controls statement declares control channels to be used by system -administrators to affect the operation of the local nameserver. These -control channels are used by the rndc utility to send commands to and -retrieve non-DNS results from a nameserver. - -An inet control channel is a TCP/IP socket accessible to the Internet, -created at the specified ip_port on the specified ip_addr. If no port -is specified, port 953 is used by default. "*" cannot be used for -ip_port. - -The ability to issue commands over the control channel is restricted -by the allow and keys clauses. Connections to the control channel are -permitted based on the address permissions in address_match_list. -key_id members of the address_match_list are ignored, and instead are -interpreted independently based the key_list. Each key_id in the -key_list is allowed to be used to authenticate commands and responses -given over the control channel by digitally signing each message -between the server and a command client (see rndc in section 3.4.1.2). -All commands to the control channel must be signed by one of its -specified keys to be honored. - -For the initial release of BIND 9.0.0, only one command is possible -over the command channel, the command to reload the server. We will -expand command set in future releases. - -The UNIX control channel type of BIND 8 is not supported in BIND -9.0.0, and is not expected to be added in future releases. If it is -present in the controls statement from a BIND 8 configuration file, a -non-fatal warning will be logged. - -6.2.5 include Statement Grammar - -include filename ; - -6.2.6 include Statement Definition and Usage - -The include statement inserts the specified file at the point that the -include statement is encountered. The include statement facilitates the -administration of configuration files by permitting the reading or writing -of some things but not others. For example, the statement could include -private keys that are readable only by a nameserver. - -6.2.7 key Statement Grammar - -key key_id { -algorithm string; -secret string; -}; - -6.2.8 key Statement Definition and Usage - -The key statement defines a shared secret key for use with TSIG. See TSIG. - -The key_id, also known as the key name, is a domain name uniquely -identifying the key. It can be used in a "server" statement to cause -requests sent to that server to be signed with this key, or in address match -lists to verify that incoming requests have been signed with a key matching -this name, algorithm, and secret. - -The algorithm_id is a string that specifies a security/authentication -algorithm. The only algorithm currently supported with TSIG authentication -is hmac-md5. The secret_string is the secret to be used by the algorithm, -and is treated as a base-64 encoded string. - -6.2.9 logging Statement Grammar - -logging { - [ channel channel_name { - ( file path name - [ versions ( number | unlimited ) ] - [ size size spec ] - | syslog ( syslog_facility - | null ); - [ severity (critical | error | warning | notice | - info | debug [ level ] | dynamic ; ] - [ print-category yes or no; - [ print-severity yes or no; ] - [ print-time yes or no; ] - }; ] - [ category category_name { - channel_name ; [ channel_name ; ... ] - }; ] - ... -}; - -6.2.10 logging Statement Definition and Usage - -The logging statement configures a wide variety of logging options for the -nameserver. Its channel phrase associates output methods, format options and -severity levels with a name that can then be used with the category phrase -to select how various classes of messages are logged. - -Only one logging statement is used to define as many channels and categories -as are wanted. If there is no logging statement, the logging configuration -will be: - -logging { - category "default" { "default_syslog"; "default_debug"; }; - }; - -In BIND 9, the logging configuration is only established when the entire -configuration file has been parsed. In BIND 8, it was established as soon as -the logging statement was parsed. When the server is starting up, all -logging messages regarding syntax errors in the configuration file go to the -default channels, or to standard error if the " -g " option was specified. - -6.2.10.1 The channel Phrase - -All log output goes to one or more channels ; you can make as many of them -as you want. - -Every channel definition must include a clause that says whether messages -selected for the channel go to a file, to a particular syslog facility, or -are discarded. It can optionally also limit the message severity level that -will be accepted by the channel (the default is info), and whether to -include a named -generated time stamp, the category name and/or severity -level (the default is not to include any). - -The word null as the destination option for the channel will cause all -messages sent to it to be discarded; in that case, other options for the -channel are meaningless. - -The file clause can include limitations both on how large the file is -allowed to become, and how many versions of the file will be saved each time -the file is opened. - -The size option for files is simply a hard ceiling on log growth. If the -file ever exceeds the size, then named will not write anything more to it -until the file is reopened; exceeding the size does not automatically -trigger a reopen. The default behavior is not to limit the size of the file. - -If you use the version log file option, then named will retain that many -backup versions of the file by renaming them when opening. For example, if -you choose to keep 3 old versions of the file lamers.log then just before it -is opened lamers.log.1 is renamed to lamers.log.2, lamers.log.0 is renamed -to lamers.log.1, and lamers.log is renamed to lamers.log.0. No rolled -versions are kept by default; any existing log file is simply appended. The -unlimited keyword is synonymous with 99 in current BIND releases. - -Example usage of the size and versions options: - - channel "an_example_channel" { - file "example.log" versions 3 size 20m; - print-time yes; - print-category yes; - }; - -The argument for the syslog clause is a syslog facility as described in the -syslog man page. How syslog will handle messages sent to this facility is -described in the syslog.conf man page. If you have a system which uses a -very old version of syslog that only uses two arguments to the openlog() -function, then this clause is silently ignored. - -The severity clause works like syslog's "priorities," except that they -can also be used if you are writing straight to a file rather than -using syslog. Messages which are not at least of the severity level -given will not be selected for the channel; messages of higher -severity levels will be accepted. - -If you are using syslog, then the syslog.conf priorities will also -determine what eventually passes through. For example, defining a channel -facility and severity as daemon and debug but only logging daemon.warning -via syslog.conf will cause messages of severity info and notice to be -dropped. If the situation were reversed, with named writing messages of only -warning or higher, then syslogd would print all messages it received from -the channel. - -The server can supply extensive debugging information when it is in -debugging mode. If the server's global debug level is greater than -zero, then debugging mode will be active. The global debug level is -set either by starting the named server with the " -d " flag followed -by a positive integer, or by running rndc trace (the latter method is -not yet implemented). The global debug level can be set to zero, and -debugging mode turned off, by running ndc notrace. All debugging -messages in the server have a debug level, and higher debug levels -give more detailed output. Channels that specify a specific debug -severity, for example: - - channel "specific_debug_level" { - file "foo"; - severity debug 3; - }; - -will get debugging output of level 3 or less any time the server is in -debugging mode, regardless of the global debugging level. Channels with -dynamic severity use the server's global level to determine what messages to -print. - -If print-time has been turned on, then the date and time will be logged. -print-time may be specified for a syslog channel, but is usually pointless -since syslog also prints the date and time. If print-category is requested, -then the category of the message will be logged as well. Finally, if -print-severity is on, then the severity level of the message will be logged. -The print- options may be used in any combination, and will always be -printed in the following order: time, category, severity. Here is an example -where all three print-options are on: - -28-Feb-2000 15:05:32.863 general: notice: running - -There are four predefined channels that are used for named's default -logging as follows. How they are used is described in the category Phrase. - - channel "default_syslog" { - syslog daemon; // end to syslog's daemon - // facility - severity info; // only send priority info - // and higher - }; - channel "default_debug" { - file "named.run"; // write to named.run in - // the working directory - // Note: stderr is used instead - // of "named.run" - // if the server is started - // with the '-f' option. - severity dynamic // log at the server's - // current debug level - }; - channel "default_stderr" { // writes to stderr - file ""; // this is illustrative only; - // there's currently no way of - // specifying an internal file - // descriptor in the - // configuration language. - severity info; // only send priority info - // and higher - }; - channel "null" { - null; // toss anything sent to - // this channel - }; - -The default_debug channel normally writes to a file named.run in the -server's working directory. For security reasons, when the "-u" -command line option is used, the named.run file is created only after -named has changed to the new UID, and any debug output generated while -named is starting up and still running as root is discarded. If you -need to capture this output, you must run the server with the "-g" -option and redirect standard error to a file. - -Once a channel is defined, it cannot be redefined. Thus you cannot -alter the built-in channels directly, but you can modify the default -logging by pointing categories at channels you have defined. - -6.2.10.2 The category Phrase - -There are many categories, so you can send the logs you want to see wherever -you want, without seeing logs you don't want. If you don't specify a list of -channels for a category, then log messages in that category will be sent to -the default category instead. If you don't specify a default category, the -following "default default" is used: - -category "default" { "default_syslog"; "default_debug"; }; - -As an example, let's say you want to log security events to a file, but you -also want keep the default logging behavior. You'd specify the following: - -channel "my_security_channel" { - file "my_security_file"; - severity info; -}; -category "security" { - "my_security_channel"; - "default_syslog"; - "default_debug"; -}; - -To discard all messages in a category, specify the null channel: - -category "xfer-out" { "null"; }; -category "notify" { "null"; }; - -Following are the available categories and brief descriptions of the types -of log information they contain. More categories may be added in future -BIND releases. - - default The default category defines the logging options for those - categories where no specific configuration has been defined. - - general The catch-all. Many things still aren't classified into - categories, and they all end up here. - - database Messages relating to the databases used internally by the name - server to store zone and cache data. - - security Approval and denial of requests. - - config Configuration file parsing and processing. - - resolver DNS resolution, such as the recursive lookups performed on behalf - of clients by a caching name server. - - xfer-in Zone transfers the server is receiving. - - xfer-out Zone transfers the server is sending. - - notify The NOTIFY protocol. - - client Processing of client requests. - - network Network operations. - - update Dynamic updates. - -6.2.11 options Statement Grammar - -This is the grammar of the option statement in the named.conf file: - -options { - - [ version version_string; ] - [ directory path_name; ] - [ named-xfer path_name; ] - [ tkey-domain domainname; ] - [ tkey-dhkey key_name key_tag; ] - [ dump-file path_name; ] - [ memstatistics-file path_name; ] - [ pid-file path_name; ] - [ statistics-file path_name; ] - [ auth-nxdomain yes_or_no; ] - [ deallocate-on-exit yes_or_no; ] - [ dialup yes_or_no; ] - [ fake-iquery yes_or_no; ] - [ fetch-glue yes_or_no; ] - [ has-old-clients yes_or_no; ] - [ host-statistics yes_or_no; ] - [ multiple-cnames yes_or_no; ] - [ notify yes_or_no; ] - [ recursion yes_or_no; ] - [ rfc2308-type1 yes_or_no; ] - [ use-id-pool yes_or_no; ] - [ maintain-ixfr-base yes_or_no; ] - [ forward ( only | first ); ] - [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ] - [ check-names ( master | slave | response )( warn | fail | ignore ); ] - [ allow-query { address_match_list }; ] - [ allow-transfer { address_match_list }; ] - [ allow-recursion { address_match_list }; ] - [ blackhole { address_match_list }; ] - [ listen-on [ port ip_port ] { address_match_list }; ] - [ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ] - [ max-transfer-time-in number; ] - [ max-transfer-time-out number; ] - [ max-transfer-idle-in number; ] - [ max-transfer-idle-out number; ] - [ tcp-clients number; ] - [ recursive-clients number; ] - [ serial-queries number; ] - [ transfer-format ( one-answer | many-answers ); ] - [ transfers-in number; ] - [ transfers-out number; ] - [ transfers-per-ns number; ] - [ transfer-source ip4_addr; ] - [ transfer-source-v6 ip6_addr; ] - [ also-notify { ip_addr; [ ip_addr; ... ] }; ] - [ max-ixfr-log-size number; ] - [ coresize size_spec ; ] - [ datasize size_spec ; ] - [ files size_spec ; ] - [ stacksize size_spec ; ] - [ cleaning-interval number; ] - [ heartbeat-interval number; ] - [ interface-interval number; ] - [ statistics-interval number; ] - [ topology { address_match_list }; ] - [ sortlist { address_match_list }; ] - [ rrset-order { order_spec ; [ order_spec ; ... ] ] }; - [ lame-ttl number; ] [ max-ncache-ttl number; ] - [ max-cache-ttl number; ] - [ sig-validity-interval number ; ] - [ min-roots number; ] - [ use-ixfr yes_or_no ; ] - [ treat-cr-as-space yes_or_no ; ] -}; - -6.2.12 options Statement Definition and Usage - -The options statement sets up global options to be used by BIND. This -statement may appear only once in a configuration file. If more than one -occurrence is found, the first occurrence determines the actual options -used, and a warning will be generated. If there is no options statement, an -options block with each option set to its default will be used. - - version The version the server should report via a query of - name version.bind in class chaos. The default is the - real version number of this server. - - directory The working directory of the server. Any non-absolute - pathnames in the configuration file will be taken as - relative to this directory. The default location for - most server output files (e.g. named.run) is this - directory. If a directory is not specified, the working - directory defaults to '.', the directory from which - the server was started. The directory specified should - be an absolute path. - - named-xfer This option is obsolete. It was used in BIND 8 to - specify the pathname to the named-xfer program. In - BIND 9, no separate named-xfer program is needed; its - functionality is built into the name server. - - tkey-domain The domain appended to the names of all shared keys - generated with TKEY. When a client requests a TKEY - exchange, it may or may not specify the desired name - for the key. If present, the name of the shared key - will be " client specified part " + " tkey-domain ". - Otherwise, the name of the shared key will be " random - hex digits " + " tkey-domain ". In most cases, the - domainname should be the server's domain name. - - tkey-dhkey The Diffie-Hellman key used by the server to generate - shared keys with clients using the Diffie-Hellman mode - of TKEY. The server must be able to load the public - and private keys from files in the working directory. - In most cases, the keyname should be the server's host - name. - - dump-file The pathname of the file the server dumps the database - to when it receives SIGINT signal (ndc dumpdb). If - not specified, the default is named_dump.db. Not yet - implemented in BIND 9. - - memstatistics-file The pathname of the file the server writes memory usage - statistics to on exit. If not specified, the default is - named.memstats. Not yet implemented in BIND 9. - - pid-file The pathname of the file the server writes its process - ID in. If not specified, the default is operating - system dependent, but is usually - /var/run/named.pid or /etc/named.pid. The pid-file is - used by programs that want to send signals to the - running nameserver. - - statistics-file The pathname of the file the server appends statistics - to. If not specified, the default is named.stats. Not - yet implemented in BIND 9. - -6.2.12.1 Boolean Options - - auth-nxdomain If yes, then the AA bit is always set on NXDOMAIN - responses, even if the server is not actually - authoritative. The default is no ; this is a change - from BIND 8. If you are using very old DNS software, - you may need to set it to yes. - - deallocate-on-exit This option was used in BIND 8 to enable checking for - memory leaks on exit. BIND 9 ignores the option and - always performs the checks. - - dialup If yes, then the server treats all zones as if they - are doing zone transfers across a dial on demand dialup - link, which can be brought up by traffic originating - from this server. This has different effects according - to zone type and concentrates the zone maintenance so - that it all happens in a short interval, once every - heartbeat-interval and hopefully during the one call. - It also suppresses some of the normal zone maintenance - traffic. The default is no. - The dialup option may also be specified in the zone - statement, in which case it overrides the options - dialup statement. - If the zone is a master then the server will send out a - NOTIFY request to all the slaves. This will trigger the - zone serial number check in the slave (providing it - supports NOTIFY) allowing the slave to verify the zone - while the connection is active. - If the zone is a slave or stub then the server will - suppress the regular "zone up to date" queries and only - perform them when the - heartbeat-interval expires. Not yet implemented in - BIND 9. - - fake-iquery In BIND 8, this option was used to enable simulating - the obsolete DNS query type IQUERY. BIND 9 never does - IQUERY simulation. - - fetch-glue (Information present outside of the authoritative nodes - in the zone is called glue information). If yes (the - default), the server will fetch glue resource records - it doesn't have when constructing the additional data - section of a response. fetch-glue no can be used in - conjunction with recursion no to prevent the server's - cache from growing or becoming corrupted (at the cost - of requiring more work from the client). Not yet - implemented in BIND 9. - - has-old-clients This option was incorrectly implemented in BIND 8, and - is ignored by BIND 9. To achieve the intended effect of - has-old-clients yes, specify the two separate options - auth-nxdomain yes and rfc2308-type1 no instead. - - host-statistics If yes, then statistics are kept for every host that - the nameserver interacts with. The default is no. - Note: turning on host-statistics can consume huge - amounts of memory. Not yet implemented in BIND 9. - - maintain-ixfr-base This option is obsolete. It was used in BIND 8 to - determine whether a transaction log was kept for - Incremental Zone Transfer. BIND 9 maintains a - transaction log whenever possible. If you need to - disable outgoing incremental zone transfers, use - provide-ixfr no. - - multiple-cnames This option was used in BIND 8 to allow a domain name - to allow multiple CNAME records in violation of the DNS - standards. BIND 9 currently does not check for multiple - CNAMEs in zone data loaded from master files, but such - checks may be introduced in a later release. BIND 9 - always strictly enforces the CNAME rules in dynamic - updates. - - notify If yes (the default), DNS NOTIFY messages are sent when - a zone the server is authoritative for changes. See - Notify, for more information. The notify option may - also be specified in the zone statement, in which case - it overrides the options notify statement. It would - only be necessary to turn off this option if it caused - slaves to crash. - - recursion If yes, and a DNS query requests recursion, then the - server will attempt to do all the work required to - answer the query. If recursion is not on, the server - will return a referral to the client if it doesn't know - the answer. The default is yes. See also fetch-glue - above. - - rfc2308-type1 Setting this to yes will cause the server to send NS - records along with the SOA record for negative answers. - The default is no. Not yet implemented in BIND 9. - - use-id-pool This option is obsolete. BIND 9 always allocates query - IDs from a pool. - - treat-cr-as-space This option was used in BIND 8 to make the server treat - "\r" characters the same way as " " or "\t", - to facilitate loading of zone files on a UNIX system - that were generated on an NT or DOS machine. In BIND 9, - both UNIX "\n" and NT/DOS "\r\n" newlines are - always accepted, and the option is ignored. - -6.2.12.2 Forwarding - -The forwarding facility can be used to create a large site-wide cache on a -few servers, reducing traffic over links to external nameservers. It can -also be used to allow queries by servers that do not have direct access to -the Internet, but wish to look up exterior names anyway. Forwarding occurs -only on those queries for which the server is not authoritative and does not -have the answer in its cache. - - - forward This option is only meaningful if the forwarders list is not - empty. A value of first, the default, causes the server to - query the forwarders first, and if that doesn't answer the - question the server will then look for the answer itself. If - only is specified, the server will only query the forwarders. - - forwarders Specifies the IP addresses to be used for forwarding. The - default is the empty list (no forwarding). - -Forwarding can also be configured on a per-domain basis, allowing for the -global forwarding options to be overridden in a variety of ways. You can set -particular domains to use different forwarders, or have a different forward -only/first behavior, or not forward at all. See zone Statement Grammar for -more information. - -6.2.12.3 Name Checking - -The server can check domain names based upon their expected client contexts. -For example, a domain name used as a hostname can be checked for compliance -with the RFCs defining valid hostnames. - -Three checking methods are available: - - ignore No checking is done. - - warn Names are checked against their expected client contexts. Invalid - names are logged, but processing continues normally. - - fail Names are checked against their expected client contexts. Invalid - names are logged, and the offending data is rejected. - -The server can check names in three areas: master zone files, slave zone -files, and in responses to queries the server has initiated. If check-names -response fail has been specified, and answering the client's question would -require sending an invalid name to the client, the server will send a -REFUSED response code to the client. - -The defaults are: - - check-names master fail; - check-names slave warn; - check-names response ignore; - -check-names may also be specified in the zone statement, in which case it -overrides the options check-names statement. When used in a zone statement, -the area is not specified because it can be deduced from the zone type. - -Name checking is not yet implemented in BIND 9. - -6.2.12.4 Access Control - -Access to the server can be restricted based on the IP address of the -requesting system. See Address Match Lists for details on how to specify IP -address lists. - - allow-query Specifies which hosts are allowed to ask ordinary - questions. allow-query may also be specified in the zone - statement, in which case it overrides the options - allow-query statement. If not specified, the default is to - allow queries from all hosts. - - allow-recursion Specifies which hosts are allowed to make recursive - queries through this server. If not specified, the default - is to allow recursive queries from all hosts. - - allow-transfer Specifies which hosts are allowed to receive zone - transfers from the server. allow-transfer may also be - specified in the zone statement, in which case it - overrides the options allow-transfer statement. If not - specified, the default is to allow transfers from all - hosts. - - blackhole Specifies a list of addresses that the server will not - accept queries from or use to resolve a query. Queries - from these addresses will not be responded to. The default - is none. Not yet implemented in BIND 9. - -6.2.12.5 Interfaces - -The interfaces and ports that the server will answer queries from may be -specified using the listen-on option. listen-on takes an optional port, and -an address_match_list. The server will listen on all interfaces allowed by -the address match list. If a port is not specified, port 53 will be used. - -Multiple listen-on statements are allowed. For example, - -listen-on { 5.6.7.8; }; -listen-on port 1234 { !1.2.3.4; 1.2/16; }; - -will enable the nameserver on port 53 for the IP address 5.6.7.8, and on -port 1234 of an address on the machine in net 1.2 that is not 1.2.3.4. - -If no listen-on is specified, the server will listen on port 53 on all -interfaces. - -The listen-on-v6 option is used to specify the ports on which the server -will listen for incoming queries sent using IPv6. - -The server does not bind a separate socket to each IPv6 interface address as -it does for IPv4. Instead, it always listens on the IPv6 wildcard address. -Therefore, the only values allowed for the address_match_list argument to -the listen-on-v6 statement are " { any; } " and " { none; } ". - -Multiple listen-on-v6 options can be used to listen on multiple ports: - -listen-on-v6 port 53 { any; }; -listen-on-v6 port 1234 { any; }; - -To make the server not listen on any IPv6 address, use - -listen-on-v6 { none; }; - -If no listen-on-v6 statement is specified, the server will listen on port 53 -on the IPv6 wildcard address. - -6.2.12.6 Query Address - -If the server doesn't know the answer to a question, it will query other -nameservers. query-source specifies the address and port used for such -queries. For queries sent over IPv6, there is a separate query-source-v6 -option. If address is * or is omitted, a wildcard IP address (INADDR_ANY) -will be used. If port is * or is omitted, a random unprivileged port will be -used. The defaults are - -query-source address * port *; -query-source-v6 address * port * - -Note: query-source currently applies only to UDP queries; TCP queries always -use a wildcard IP address and a random unprivileged port. - -6.2.12.7 Zone Transfers - -BIND has mechanisms in place to facilitate zone transfers and set limits on -the amount of load that transfers place on the system. The following options -apply to zone transfers. - - - - also-notify Defines a global list of IP addresses that are also - sent NOTIFY messages whenever a fresh copy of the - zone is loaded. This helps to ensure that copies of - the zones will quickly converge on stealth servers. - If an also-notify list is given in a zone statement, - it will override the options also-notify statement. - When a zone notify statement is set to no, the IP - addresses in the global also-notify list will not be - sent NOTIFY messages for that zone. The default is - the empty list (no global notification list). - - - max-transfer-time-in Inbound zone transfers running longer than this many - minutes will be terminated. The default is 120 - minutes (2 hours). - - max-transfer-idle-in Inbound zone transfers making no progress in this - many minutes will be terminated. The default is 60 - minutes (1 hour). - - max-transfer-time-out Outbound zone transfers running longer than this - many minutes will be terminated. The default is 120 - minutes (2 hours). - - max-transfer-idle-out Outbound zone transfers making no progress in this - many minutes will be terminated. The default is 60 - minutes (1 hour). - - serial-queries Slave servers will periodically query master servers - to find out if zone serial numbers have changed. - Each such query uses a minute amount of the slave - server's network bandwidth, but more importantly - each query uses a small amount of memory in the - slave server while waiting for the master server to - respond. The serial-queries option sets the maximum - number of concurrent serial-number queries allowed - to be outstanding at any given time. The default is - 4. Note: If a server loads a large (tens or hundreds - of thousands) number of slave zones, then this limit - should be raised to the high hundreds or low - thousands, otherwise the slave server may never - actually become aware of zone changes in the master - servers. Beware, though, that setting this limit - arbitrarily high can spend a considerable amount of - your slave server's network, CPU, and memory - resources. As with all tunable limits, this one - should be changed gently and monitored for its - effects. Not yet implemented in BIND 9. - - transfer-format The server supports two zone transfer methods. - one-answer uses one DNS message per resource record - transferred. many-answers packs as many resource - records as possible into a message. many-answers is - more efficient, but is only known to be understood - by BIND 9, BIND 8.x and patched versions of - BIND 4.9.5. The default is many-answers. - transfer-format may be overridden on a per-server - basis by using the server statement. - - transfers-in The maximum number of inbound zone transfers that - can be running concurrently. The default value is 10. - Increasing transfers-in may speed up the - convergence of slave zones, but it also may increase - the load on the local system. - - transfers-out The maximum number of outbound zone transfers that - can be running concurrently. Zone transfer requests - in excess of the limit will be refused. The default - value is 10. - - transfers-per-ns The maximum number of inbound zone transfers that - can be concurrently transferring from a given remote - nameserver. The default value is 2. Increasing - transfers-per-ns may speed up the convergence of - slave zones, but it also may increase the load on - the remote nameserver. transfers-per-ns may be - overridden on a per-server basis by using the - transfers phrase of the server statement. - - transfer-source transfer-source determines which local address will - be bound to IPv4 TCP connections used to fetch zones - transferred inbound by the server. If not set, it - defaults to a system controlled value which will - usually be the address of the interface "closest to" - the remote end. This address must appear in the - remote end's allow-transfer option for the zone - being transferred, if one is specified. This - statement sets the transfer-source for all zones, - but can be overridden on a per-zone basis by - including a - transfer-source statement within the zone block in - the configuration file. - - transfer-source-v6 The same as transfer-source, except zone transfers - are performed using IPv6. - -6.2.12.8 Resource Limits - -The server's usage of many system resources can be limited. Some operating -systems don't support some of the limits. On such systems, a warning will be -issued if the unsupported limit is used. Some operating systems don't -support limiting resources. - -Scaled values are allowed when specifying resource limits. For example, 1G -can be used instead of 1073741824 to specify a limit of one gigabyte. -unlimited requests unlimited use, or the maximum available amount. default -uses the limit that was in force when the server was started. See the -description of size_spec in Configuration File Elements for more details. - - - - coresize The maximum size of a core dump. The default is default. - Not yet implemented in BIND 9. - - datasize The maximum amount of data memory the server may use. - The default is default. Not yet implemented in BIND 9. - - The maximum number of files the server may have open - concurrently. The default is unlimited. Note: on some - operating systems the server cannot set an unlimited - value and cannot determine the maximum number of open - files files the kernel can support. On such systems, choosing - unlimited will cause the server to use the larger of the - rlim_max for RLIMIT_NOFILE and the value returned by - sysconf(_SC_OPEN_MAX). If the actual kernel limit is - larger than this value, use limit files to specify the - limit explicitly. Not yet implemented in BIND 9. - - max-ixfr-log-size The max-ixfr-log-size will be used in a future release - of the server to limit the size of the transaction log - kept for Incremental Zone Transfer. Not yet implemented - in BIND 9. - - recursive-clients The maximum number of simultaneous recursive lookups the - server will perform on behalf of clients. The default is - 1000. - - stacksize The maximum amount of stack memory the server may use. - The default is default. Not yet implemented in BIND 9. - - tcp-clients The maximum number of simultaneous client TCP - connections that the server will accept. The default is - 100. - -Resource limits are not yet implemented in BIND 9. - -6.2.12.9 Periodic Task Intervals - - - - cleaning-interval The server will remove expired resource records from - the cache every cleaning-interval minutes. The default - is 60 minutes. If set to 0, no periodic cleaning will - occur. - - heartbeat-interval The server will perform zone maintenance tasks for all - zones marked dialup yes whenever this interval - expires. The default is 60 minutes. Reasonable values - are up to 1 day (1440 minutes). If set to 0, no zone - maintenance for these zones will occur. Not yet - implemented in BIND 9. - - interface-interval The server will scan the network interface list every - interface-interval minutes. The default is 60 minutes. - If set to 0, interface scanning will only occur when - the configuration file is loaded. After the scan, - listeners will be started on any new interfaces - (provided they are allowed by the listen-on - configuration). Listeners on interfaces that have gone - away will be cleaned up. - - statistics-interval Nameserver statistics will be logged every - statistics-interval minutes. The default is 60. If - set to 0, no statistics will be logged. Not yet - implemented in BIND 9. - -6.2.12.10 Topology - -All other things being equal, when the server chooses a nameserver to query -from a list of nameservers, it prefers the one that is topologically closest -to itself. The topology statement takes an address_match_list and interprets -it in a special way. Each top-level list element is assigned a distance. -Non-negated elements get a distance based on their position in the list, -where the closer the match is to the start of the list, the shorter the -distance is between it and the server. A negated match will be assigned the -maximum distance from the server. If there is no match, the address will get -a distance which is further than any non-negated list element, and closer -than any negated element. For example, - - topology { - 10/8; - !1.2.3/24; - { 1.2/16; 3/8; }; - }; - -will prefer servers on network 10 the most, followed by hosts on network -1.2.0.0 (netmask 255.255.0.0) and network 3, with the exception of hosts on -network 1.2.3 (netmask 255.255.255.0), which is preferred least of all. - -The default topology is - - topology { localhost; localnets; }; - -The topology option is not yet implemented in BIND 9. - -6.2.12.11 The sortlist Statement - -Resource Records (RRs) are the data associated with the names in a domain -name space. The data is maintained in the form of sets of RRs. The order of -RRs in a set is, by default, not significant. Therefore, to control the -sorting of records in a set of resource records, or RRset, you must use the -sortlist statement. - -RRs are explained more fully in See Types of Resource Records and When to -Use Them. Specifications for RRs are documented in RFC 1035. - -When returning multiple RRs the nameserver will normally return them in -Round Robin order, that is, after each request the first RR is put at the -end of the list. The client resolver code should rearrange the RRs as -appropriate, that is, using any addresses on the local net in preference to -other addresses. However, not all resolvers can do this or are correctly -configured. When a client is using a local server the sorting can be -performed in the server, based on the client's address. This only requires -configuring the nameservers, not all the clients. - -The sortlist statement (see below) takes an address_match_list and -interprets it even more specifically than the topology statement does (see -Topology). Each top level statement in the sortlist must itself be an -explicit address_match_list with one or two elements. The first element -(which may be an IP address, an IP prefix, an ACL name or a nested -address_match_list) of each top level list is checked against the source -address of the query until a match is found. - -Once the source address of the query has been matched, if the top level -statement contains only one element, the actual primitive element that -matched the source address is used to select the address in the response to -move to the beginning of the response. If the statement is a list of two -elements, then the second element is treated the same as the -address_match_list in a topology statement. Each top level element is -assigned a distance and the address in the response with the minimum -distance is moved to the beginning of the response. - -In the following example, any queries received from any of the addresses of -the host itself will get responses preferring addresses on any of the -locally connected networks. Next most preferred are addresses on the -192.168.1/24 network, and after that either the 192.168.2/24 or -192.168.3/24 network with no preference shown between these two networks. -Queries received from a host on the 192.168.1/24 network will prefer other -addresses on that network to the 192.168.2/24 and -192.168.3/24 networks. Queries received from a host on the 192.168.4/24 or -the 192.168.5/24 network will only prefer other addresses on their directly -connected networks. - -sortlist { - { localhost; // IF the local host - { localnets; // THEN first fit on the - 192.168.1/24; // following nets - { 192,168.2/24; 192.168.3/24; }; }; }; - { 192.168.1/24; // IF on class C 192.168.1 - { 192.168.1/24; // THEN use .1, or .2 or .3 - { 192.168.2/24; 192.168.3/24; }; }; }; - { 192.168.2/24; // IF on class C 192.168.2 - { 192.168.2/24; // THEN use .2, or .1 or .3 - { 192.168.1/24; 192.168.3/24; }; }; }; - { 192.168.3/24; // IF on class C 192.168.3 - { 192.168.3/24; // THEN use .3, or .1 or .2 - { 192.168.1/24; 192.168.2/24; }; }; }; - { { 192.168.4/24; 192.168.5/24; }; - // if .4 or .5, prefer that net - }; -}; - -The following example will give reasonable behavior for the local host and -hosts on directly connected networks. It is similar to the behavior of the -address sort in BIND 8.x. Responses sent to queries from the local host will -favor any of the directly connected networks. Responses sent to queries from -any other hosts on a directly connected network will prefer addresses on -that same network. Responses to other queries will not be sorted. - -sortlist { - { localhost; localnets; }; - { localnets; }; -}; - -The sortlist option is not yet implemented in BIND 9. - -6.2.12.12 RRset Ordering - -When multiple records are returned in an answer it may be useful to -configure the order of the records placed into the response. For example, -the records for a zone might be configured always to be returned in the -order they are defined in the zone file. Or perhaps a random shuffle of the -records as they are returned is wanted. The rrset-order statement permits -configuration of the ordering made of the records in a multiple record -response. The default, if no ordering is defined, is a cyclic ordering -(round robin). - -An order_spec is defined as follows: - -[ class class_name ][ type type_name ][ name "domain_name"] - order ordering - -If no class is specified, the default is ANY. If no type is specified, the -default is ANY. If no name is specified, the default is "*". - -The legal values for ordering are: - - fixed Records are returned in the order they are defined in the zone - file. - - random Records are returned in some random order. - - cyclic Records are returned in a round-robin order. - -For example: - - rrset-order { - class IN type A name "host.example.com" order random; - order cyclic; - }; - -will cause any responses for type A records in class IN that have -"host.example.com" as a suffix, to always be returned in random -order. All other records are returned in cyclic order. - -If multiple rrset-order statements appear, they are not combined--the last -one applies. - -If no rrset-order statement is specified, then a default one of: - - rrset-order { class ANY type ANY name "*"; order cyclic ; - }; - -is used. - -The rrset-order statement is not yet implemented in BIND 9. - -6.2.12.13 Tuning - - - lame-ttl Sets the number of seconds to cache a lame server - indication. 0 disables caching. (This is NOT - recommended.) Default is 600 (10 minutes). Maximum - value is 1800 (30 minutes). Not yet implemented in - BIND 9. - - max-ncache-ttl To reduce network traffic and increase performance - the server stores negative answers. max-ncache-ttl - is used to set a maximum retention time for these - answers in the server in seconds. The default - max-ncache-ttl is 10800 seconds (3 hours). - max-ncache-ttl cannot exceed 7 days and will be - silently truncated to 7 days if set to a greater - value. - - max-cache-ttl max-cache-ttl sets the maximum time for which the - server will cache ordinary (positive) answers. The - default is one week (7 days). - - min-roots The minimum number of root servers that is required - for a request for the root servers to be accepted. - Default is 2. Not yet implemented in BIND 9. - - sig-validity-interval Specifies the number of days into the future when - DNSSEC signatures automatically generated as a - result of dynamic updates (see Dynamic Update) will - expire. The default is 30 days. The signature - inception time is unconditionally set to one hour - before the current time to allow for a limited - amount of clock skew. - -6.2.12.14 Deprecated Features - -use-ixfr is deprecated in BIND 9. If you need to disable IXFR to a -particular server or servers see the information on the provide-ixfr option -in server Statement Definition and Usage. See also the description of IXFR -in the section Incremental Zone Transfers (IXFR). - -6.2.13 server Statement Grammar - -server ip_addr { - - [ bogus yes_or_no ; ] - [ provide-ixfr yes_or_no ; ] - [ request-ixfr yes_or_no ; ] - [ transfers number ; ] - [ transfer-format ( one-answer | many-answers ) ; ] - [ keys { string ; [ string ; [...]] } ; ] -}; } - -6.2.14 server Statement Definition and Usage - -The server statement defines the characteristics to be associated with a -remote nameserver. - -If you discover that a remote server is giving out bad data, marking it as -bogus will prevent further queries to it. The default value of bogus is no. -The bogus clause is not yet implemented in BIND 9. - -The provide-ixfr clause determines whether the local server, acting as -master, will respond with an incremental zone transfer when the given remote -server, a slave, requests it. If set to yes, incremental transfer will be -provided whenever possible. If set to no, all transfers to the remote -server will be nonincremental. If not set, the value of the provide-ixfr -option in the global options block is used as a default. - -The request-ixfr clause determines whether the local server, acting as a -slave, will request incremental zone transfers from the given remote server, -a master. If not set, the value of the request-ixfr option in the global -options block is used as a default. - -IXFR requests to servers that do not support IXFR will automatically fall -back to AXFR. Therefore, there is no need to manually list which servers -support IXFR and which ones do not; the global default of yes should always -work. The purpose of the provide-ixfr and request-ixfr clauses is to make it -possible to disable the use of IXFR even when both master and slave claim to -support it, for example if one of the servers is buggy and crashes or -corrupts data when IXFR is used. - -The server supports two zone transfer methods. The first, one-answer, uses -one DNS message per resource record transferred. many-answers packs as many -resource records as possible into a message. many-answers is more efficient, -but is only known to be understood by BIND 9, BIND 8.x, and patched versions -of BIND 4.9.5. You can specify which method to use for a server with the -transfer-format option. If transfer-format is not specified, the -transfer-format specified by the options statement will be used. - -transfers is used to limit the number of concurrent inbound zone transfers -from the specified server. If no transfers clause is specified, the limit is -set according to the transfers-per-ns option. - -The keys clause is used to identify a key_id defined by the key statement, -to be used for transaction security when talking to the remote server. The -key statement must come before the server statement that references it. When -a request is sent to the remote server, a request signature will be -generated using the key specified here and appended to the message. A -request originating from the remote server is not required to be signed by -this key. - -Although the grammar of the keys clause allows for multiple keys, only a -single key per server is currently supported. - -6.2.15 trusted-keys Statement Grammar - -trusted-keys { - string number number number string ; - [ string number number number string ; [...]] -}; } - -6.2.16 trusted-keys Statement Definition and Usage - -The trusted-keys statement defines DNSSEC security roots. See DNSSEC for a -description. A security root is defined when the public key for a -non-authoritative zone is known, but cannot be securely obtained through -DNS, either because it is the DNS root zone or its parent zone is unsigned. -Once a key has been configured as a trusted key, it is treated as if it had -been validated and proven secure. The resolver attempts DNSSEC validation on -all DNS data in subdomains of a security root. - -The trusted-keys statement can contain multiple key entries, each consisting -of the key's domain name, flags, protocol, algorithm, and the base-64 -representation of the key data. - -6.2.17 view Statement Grammar - - view view name { - match-clients { address_match_list } ; - [view_option; ...] - [zone_statement; ...]] -}; - -6.2.18 view Statement Definition and Usage - -The view statement is a powerful new feature of BIND 9 that lets a name -server answer a DNS query differently depending on who is asking. It is -particularly useful for implementing split DNS setups without having to run -multiple servers. - -Each view statement defines a view of the DNS namespace that will be seen by -those clients whose IP addresses match the address_match_list of the view's -match-clients clause. The order of the view statements is significant--a -client query will be resolved in the context of the first view whose -match-clients list matches the client's IP address. - -Zones defined within a view statement will be only be accessible to clients -that match the view. By defining a zone of the same name in multiple views, -different zone data can be given to different clients, for example, -"internal" and "external" clients in a split DNS setup. - -Many of the options given in the options statement can also be used within a -view statement, and then apply only when resolving queries with that view. -When no a view-specific value is given, the value in the options statement -is used as a default. Also, zone options can have default values specified -in the view statement; these view-specific defaults take precedence over -those in the options statement. - -Views are class specific. If no class is given, class IN is assumed. - -If there are no view statements in the config file, a default view that -matches any client is automatically created in class IN, and any zone -statements specified on the top level of the configuration file are -considered to be part of this default view. If any explicit view statements -are present, all zone statements must occur inside view statements. - -Here is an example of a typical split DNS setup implemented using view -statements. - -view "internal" { - // This should match our internal networks. - match-clients { 10.0.0.0/8; }; - // Provide recursive service to internal clients only. - recursion yes; - // Provide a complete view of the example.com zone - // including addresses of internal hosts. - zone "example.com" { - type master; - file "example-internal.db"; - }; - }; - - view "external" { - match-clients { any; }; - // Refuse recursive service to external clients. - recursion no; - // Provide a restricted view of the example.com zone - // containing only publicly accessible hosts. - zone "example.com" { - type master; - file "example-external.db"; - }; - }; - -6.2.19 zone Statement Grammar - -zone zone name [class] [{ - type ( master|slave|hint|stub|forward ) ; - [ allow-query { address_match_list } ; ] - [ allow-transfer { address_match_list } ; ] - [ allow-update { address_match_list } ; ] - [ update-policy { update_policy_rule[...] } ; ] - [ allow-update-forwarding { address_match_list } ; ] - [ also-notify { [ ip_addr ; [ip_addr ; [...]]] } ; ] - [ check-names (warn|fail|ignore) ; ] - [ dialup true_or_false ; ] - [ file string ; ] - [ forward (only|first) ; ] - [ forwarders { [ ip_addr ; [ ip_addr ; [...]]] } ; ] - [ ixfr-base string ; ] - [ ixfr-tmp-file string ; ] - [ maintain-ixfr-base true_or_false ; ] - [ masters [port number] { ip_addr ; [ip_addr ; [...]] } ; ] - [ max-ixfr-log-size number ; ] - [ max-transfer-idle-in number ; ] - [ max-transfer-idle-out number ; ] - [ max-transfer-time-in number ; ] - [ max-transfer-time-out number ; ] - [ notify true_or_false ; ] - [ pubkey number number number string ; ] - [ transfer-source (ip4_addr | *) ; ] - [ transfer-source-v6 (ip6_addr | *) ; ] - [ sig-validity-interval number ; ]}] -; - -6.2.20 zone Statement Definition and Usage - -6.2.20.1 Zone Types - - master The server has a master copy of the data for the zone and will be - able to provide authoritative answers for it. - - slave A slave zone is a replica of a master zone. The masters list - specifies one or more IP addresses that the slave contacts to - update its copy of the zone. If a port is specified, the slave - then checks to see if the zone is current and zone transfers will - be done to the port given. If a file is specified, then the - replica will be written to this file whenever the zone is changed, - and reloaded from this file on a server restart. Use of a file is - recommended, since it often speeds server start-up and eliminates - a needless waste of bandwidth. Note that for large numbers (in the - tens or hundreds of thousands) of zones per server, it is best to - use a two level naming scheme for zone file names. For example, a - slave server for the zone example.com might place the zone - contents into a file called - ex/example.com where ex/ is just the first two letters of the zone - name. (Most operating systems behave very slowly if you put 100K - files into a single directory.) - -stub A stub zone is similar to a slave zone, except that it replicates - only the NS records of a master zone instead of the entire zone. - Stub zones are not a standard part of the DNS; they are a - peculiarity of BIND 4 and BIND 8 that relies heavily on the - particular way the zone data is structured in those servers. - BIND 9 attempts to emulate the BIND 4/8 stub zone feature for - backwards compatibility, but we do not recommend its use in new - configurations. - In BIND 4/8, zone transfers of a parent zone included the NS - records from stub children of that zone. This meant that, in some - cases, users could get away with configuring child stubs only in - the master server for the parent zone. BIND 9 never mixes together - zone data from different zones in this way. Therefore, if a BIND 9 - master serving a parent zone has child stub zones configured, all - the slave servers for the parent zone also need to have the same - child stub zones configured.. - - forward A "forward zone" is a way to configure forwarding on a per-domain - basis. A zone statement of type forward can contain a forward - and/or forwarders statement, which will apply to queries within - the domain given by the zone name. If no forwarders statement is - present or an empty list for forwarders is given, then no - forwarding will be done for the domain, cancelling the effects of - any forwarders in the options statement. Thus if you want to use - this type of zone to change the behavior of the global forward - option (that is, "forward first to", then "forward only", or vice - versa, but want to use the same servers as set globally) you need - to respecify the global forwarders. Domain-specific forwarding is - not yet implemented in BIND 9. - - hint The initial set of root nameservers is specified using a "hint - zone". When the server starts up, it uses the root hints to find a - root nameserver and get the most recent list of root nameservers. - If no hint zone is specified for class IN, the server users a - compiled-in default set of root servers hints. Classes other than - IN have no built-in defaults hints. - -6.2.20.2 Class - -The zone's name may optionally be followed by a class. If a class is not -specified, class IN (for Internet), is assumed. This is correct for the -vast majority of cases. - -The hesiod class is named for an information service from MIT's Project -Athena. It is used to share information about various systems databases, -such as users, groups, printers and so on. The keyword HS is a synonym for -hesiod. - -Another MIT development is CHAOSnet, a LAN protocol created in the -mid-1970s. Zone data for it can be specified with the CHAOS class. - -6.2.20.3 Zone Options - - allow-query See the description of allow-query under Access - Control. - - allow-transfer See the description of allow-transfer under Access - Control. - - allow-update Specifies which hosts are allowed to submit Dynamic DNS - updates for master zones. The default is to deny updates - from all hosts. - - update-policy Specifies a "Simple Secure Update" policy. See - description in Dynamic Update Policies. - - allow-update-forwarding Specifies which hosts are allowed to submit - Dynamic DNS updates to slave zones to be forwarded - to the master. The default is to deny update - forwarding from all hosts. Update forwarding is - not yet implemented. - - also-notify Only meaningful if notify is active for this zone. The - set of machines that will receive a DNS - NOTIFY message for this zone is made up of - all the listed nameservers (other than the - primary master) for the zone plus any IP - addresses specified with also-notify. - also-notify is not meaningful for stub - zones. The default is the empty list. - - check-names See Name Checking. - Not yet implemented in BIND 9. - - dialup See the description of dialup under Boolean - Options. - Not yet implemented in BIND 9. - - forward Only meaningful if the zone has a forwarders list. - The only value causes the lookup to fail after - trying the forwarders and getting no answer, while - first would allow a normal lookup to be tried. - Not yet implemented in BIND 9. - - forwarders Used to override the list of global forwarders. If - it is not specified in a zone of type forward, no - forwarding is done for the zone; the global - options are not used. - Not yet implemented in BIND 9. - - ixfr-base Was used in BIND 8 to specify the name of the - transaction log (journal) file for dynamic update - and IXFR. BIND 9 ignores the option and constructs - the name of the journal file by appending ".jnl" - to the name of the zone file. - - max-transfer-time-in See the description of - max-transfer-time-in under Zone Transfers. - - max-transfer-idle-in See the description of - max-transfer-idle-in under Zone Transfers. - - max-transfer-time-out See the description of - max-transfer-time-out under Zone Transfers. - - max-transfer-idle-out See the description of - max-transfer-idle-out under Zone Transfers. - - notify See the description of notify under Boolean - Options. - - pubkey In BIND 8, this option was intended for specifying - a public zone key for verification of signatures - in DNSSEC signed zones when they are loaded from - disk. BIND 9 does not verify signatures on loading - and ignores the option. - - sig-validity-interval See the description of sig-validity-interval in - Tuning. - - transfer-source Determines which local address will be bound - to the IPv4 TCP connection used to fetch this - zone. If not set, it defaults to a system - controlled value which will - usually be the address of the interface - "closest to" the remote end. If the remote - end user is an allow-transfer option for - this zone, the address, supplied by the - transfer-source option, needs to be specified - in that allow-transfer option. - - transfer-source-v6 Similar to transfer-source, but for zone transfers - performed using IPv6. - -6.2.20.4 Dynamic Update Policies - -BIND 9 supports two alternative methods of granting clients the right to -perform dynamic updates to a zone, configured by the allow-update and -update-policy option, respectively. - -The allow-update clause works the same way as in previous versions of BIND. -It grants given clients the permission to update any record of any name in -the zone. - -The update-policy clause is new in BIND 9 and allows more fine-grained -control over what updates are allowed. A set of rules is specified, where -each rule either grants or denies permissions for one or more names to be -updated by one or more identities. If the dynamic update request message is -signed (that is, it includes either a TSIG or SIG(0) record), the identity -of the signer can be determined. - -Rules are specified in the update-policy zone option, and are only -meaningful for master zones. When the update-policy statement is present, it -is a configuration error for the allow-update statement to be present. The -update-policy statement only examines the signer of a message; the source -address is not relevant. - -This is how a rule definition looks: - -( grant | deny ) identity nametype name [ types ] - -Each rule grants or denies privileges. Once a messages has successfully -matched a rule, the operation is immediately granted or denied and no -further rules are examined. A rule is matched when the signer matches the -identity field, the name matches the name field, and the type is specified -in the type field. - -The identity field specifies a name or a wildcard name. The nametype field -has 4 values: name, subdomain, wildcard, and self. - - name Matches when the updated name is the same as the name in the - name field. - subdomain Matches when the updated name is a subdomain of the name in the - name field. - wildcard Matches when the updated name is a valid expansion of the - wildcard name in the name field. - self Matches when the updated name is the same as the message signer. - The name field is ignored. - -If no types are specified, the rule matches all types except SIG, NS, SOA, -and NXT. Types may be specified by name, including "ANY" (ANY matches all -types except NXT, which can never be updated). - -6.3 Zone File - -6.3.1 Types of Resource Records and When to Use Them - -This section, largely borrowed from RFC 1034, describes the concept of a -Resource Record (RR) and explains when each is used. Since the publication -of RFC 1034, several new RRs have been identified and implemented in the -DNS. These are also included. - -6.3.1.1 Resource Records - -A domain name identifies a node. Each node has a set of resource -information, which may be empty. The set of resource information associated -with a particular name is composed of separate RRs. The order of RRs in a -set is not significant and need not be preserved by nameservers, resolvers, -or other parts of the DNS. However, sorting of multiple RRs is permitted for -optimization purposes, for example, to specify that a particular nearby -server be tried first. See The sortlist Statement and RRset Ordering for -details. - -The components of a Resource Record are - - owner namethe domain name where the RR is found. - - type an encoded 16 bit value that specifies the type of the resource - in this resource record. Types refer to abstract resources. - the time to live of the RR. This field is a 32 bit integer in - TTL units of seconds, and is primarily used by resolvers when they - cache RRs. The TTL describes how long a RR can be cached before - it should be discarded. - - class an encoded 16 bit value that identifies a protocol family or - instance of a protocol. - - RDATA the type and sometimes class-dependent data that describes the - resource. - -The following are types of valid RRs (some of these listed, although not -obsolete, are experimental (x) or historical (h) and no longer in general -use): - - A a host address. - - A6 an IPv6 address. - - AAAA Obsolete format of IPv6 address - - AFSDB(x) location of AFS database servers. Experimental. - - CNAME identifies the canonical name of an alias. - - DNAME for delegation of reverse addresses. Replaces the domain name - specified with another name to be looked up. Described in RFC 2672. - - HINFO identifies the CPU and OS used by a host. - - ISDN (x) representation of ISDN addresses. Experimental. - - KEY stores a public key associated with a DNS name. - - LOC (x) for storing GPS info. See RFC 1876. Experimental. - - MX identifies a mail exchange for the domain. See RFC 974 for details. - - NS the authoritative nameserver for the domain. - used in DNSSEC to securely indicate that RRs with an owner name in a - - NXT certain name interval do not exist in a zone and indicate what RR - types are present for an existing name. See RFC 2535 for details. - - PTR a pointer to another part of the domain name space. - - RP (x) information on persons responsible for the domain. Experimental. - - RT (x) route-through binding for hosts that do not have their own direct - wide area network addresses. Experimental. - - SIG ("signature") contains data authenticated in the secure DNS. See RFC - 2535 for details. - - SOA identifies the start of a zone of authority. - - SRV information about well known network services (replaces WKS). - - WKS (h) information about which well known network services, such as - SMTP, that a domain supports. Historical, replaced by newer RR SRV. - - X25 (x) representation of X.25 network addresses. Experimental. - -The following classes of resource records are currently valid in the DNS: - - IN the Internet system. - For information about other, older classes of RRs, see Classes of Resource - Records in the Appendix. - -RDATA is the type-dependent or class-dependent data that describes the -resource: - - A for the IN class, a 32 bit IP address. - - A6 maps a domain name to an IPv6 address, with a provision for - indirection for leading "prefix" bits. - - CNAME a domain name. - provides alternate naming to an entire subtree of the domain name - - DNAME space, rather than to a single node. It causes some suffix of a - queried name to be substituted with a name from the DNAME record's - RDATA. - - MX a 16 bit preference value (lower is better) followed by a host name - willing to act as a mail exchange for the owner domain. - - NS a fully qualified domain name. - - PTR a fully qualified domain name. - - SOA several fields. - -The owner name is often implicit, rather than forming an integral part of -the RR. For example, many nameservers internally form tree or hash -structures for the name space, and chain RRs off nodes. The remaining RR -parts are the fixed header (type, class, TTL) which is consistent for all -RRs, and a variable part (RDATA) that fits the needs of the resource being -described. - -The meaning of the TTL field is a time limit on how long an RR can be kept -in a cache. This limit does not apply to authoritative data in zones; it is -also timed out, but by the refreshing policies for the zone. The TTL is -assigned by the administrator for the zone where the data originates. While -short TTLs can be used to minimize caching, and a zero TTL prohibits -caching, the realities of Internet performance suggest that these times -should be on the order of days for the typical host. If a change can be -anticipated, the TTL can be reduced prior to the change to minimize -inconsistency during the change, and then increased back to its former value -following the change. - -The data in the RDATA section of RRs is carried as a combination of binary -strings and domain names. The domain names are frequently used as "pointers" -to other data in the DNS. - -6.3.1.2 Textual expression of RRs - -RRs are represented in binary form in the packets of the DNS protocol, and -are usually represented in highly encoded form when stored in a nameserver -or resolver. In the examples provided in RFC 1034, a style similar to that -used in master files was employed in order to show the contents of RRs. In -this format, most RRs are shown on a single line, although continuation -lines are possible using parentheses. - -The start of the line gives the owner of the RR. If a line begins with a -blank, then the owner is assumed to be the same as that of the previous RR. -Blank lines are often included for readability. - -Following the owner, we list the TTL, type, and class of the RR. Class and -type use the mnemonics defined above, and TTL is an integer before the type -field. In order to avoid ambiguity in parsing, type and class mnemonics are -disjoint, TTLs are integers, and the type mnemonic is always last. The IN -class and TTL values are often omitted from examples in the interests of -clarity. - -The resource data or RDATA section of the RR are given using knowledge of -the typical representation for the data. - -For example, we might show the RRs carried in a message as: - - ISI.EDU. MX 10 VENERA.ISI.EDU. - MX 10 VAXA.ISI.EDU - VENERA.ISI.EDU A 128.9.0.32 - A 10.1.0.52 - VAXA.ISI.EDU A 10.2.0.27 - A 128.9.0.33 - -The MX RRs have an RDATA section which consists of a 16 bit number followed -by a domain name. The address RRs use a standard IP address format to -contain a 32 bit internet address. - -This example shows six RRs, with two RRs at each of three domain names. - -Similarly we might see: - - XX.LCS.MIT.EDU. IN A 10.0.0.44 - CH A MIT.EDU. 2420 - -This example shows two addresses for XX.LCS.MIT.EDU, each of a different -class. - -6.3.2 Discussion of MX Records - -As described above, domain servers store information as a series of resource -records, each of which contains a particular piece of information about a -given domain name (which is usually, but not always, a host). The simplest -way to think of a RR is as a typed pair of datum, a domain name matched with -relevant data, and stored with some additional type information to help -systems determine when the RR is relevant. - -MX records are used to control delivery of email. The data specified in the -record is a priority and a domain name. The priority controls the order in -which email delivery is attempted, with the lowest number first. If two -priorities are the same, a server is chosen randomly. If no servers at a -given priority are responding, the mail transport agent will fall back to -the next largest priority. Priority numbers do not have any absolute meaning -- they are relevant only respective to other MX records for that domain -name. The domain name given is the machine to which the mail will be -delivered. It must have an associated A record--a CNAME is not sufficient. - -For a given domain, if there is both a CNAME record and an MX record, the MX -record is in error, and will be ignored. Instead, the mail will be delivered -to the server specified in the MX record pointed to by the CNAME. - -For example: - - example.com. IN MX 10 mail.example.com. - IN MX 10 mail2.example.com. - IN MX 20 mail.backup.org. - mail.example.com. IN A 10.0.0.1 - mail2.example.com. IN A 10.0.0.2 - -Mail delivery will be attempted to mail.example.com and mail2.example.com -(in any order), and if neither of those succeed, delivery to mail.backup.org -will be attempted. - -6.3.3 Setting TTLs - -The time to live of the RR field is a 32 bit integer represented in units of -seconds, and is primarily used by resolvers when they cache RRs. The TTL -describes how long a RR can be cached before it should be discarded. The -following three types of TTL are currently used in a zone file. - - - SOA The last field in the SOA is the negative caching TTL. This - controls how long other servers will cache no-such-domain - (NXDOMAIN) responses from you. - - The maximum time for negative caching is 3 hours (3h). - - $TTL The $TTL directive at the top of the zone file (before the SOA) - gives a default TTL for every RR without a specific TTL set. - - RR TTLs Each RR can have a TTL as the second field in the RR, which will - control how long other servers can cache the it. - -All of these TTLs default to units of seconds, though units can be -explicitly specified, for example, 1h30m. - -6.3.4 Inverse Mapping in IPv4 - -Reverse name resolution (that is, translation from IP address to name) is -achieved by means of the in-addr.arpa domain and PTR records. Entries in the -in-addr.arpa domain are made in least-to-most significant order, read left -to right. This is the opposite order to the way IP addresses are usually -written. Thus, a machine with an IP address of 10.1.2.3 would have a -corresponding in-addr.arpa name of -3.2.1.10.in-addr.arpa. This name should have a PTR resource record whose -data field is the name of the machine or, optionally, multiple PTR records -if the machine has more than one name. For example, in the example.com -domain: - - - -$ORIGIN 2.1.10.in-addr.arpa -3 IN PTR foo.example.com. - -(Note: The $ORIGIN lines in the examples are for providing context to the -examples only--they do not necessarily appear in the actual usage. They are -only used here to indicate that the example is relative to the listed -origin.) - -6.3.5 Other Zone File Directives - -The Master File Format was initially defined in RFC 1035 and has -subsequently been extended. While the Master File Format itself is class -independent all records in a Master File must be of the same class. - -Master File Directives include $ORIGIN, $INCLUDE, and $TTL. - -6.3.5.1 The $ORIGIN Directive - -Syntax: $ORIGIN < domain-name > [ < comment > ] - -$ORIGIN sets the domain name that will be appended to any unqualified -records. When a zone is first read in there is an implicit $ORIGIN -. The current $ORIGIN is appended to the domain specified -in the $ORIGIN argument if it is not absolute. - -$ORIGIN example.com -WWW CNAME MAIN-SERVER - -is equivalent to - -WWW.EXAMPLE.COM CNAME MAIN-SERVER.EXAMPLE.COM. - -6.3.5.2 The $INCLUDE Directive - -Syntax: $INCLUDE < filename > [ < origin > ] [ < comment > ] - -Read and process the file filename as if it were included into the file at -this point. If origin is specified the file is processed with $ORIGIN set to -that value, otherwise the current $ORIGIN is used. - -NOTE: The behavior when origin is specified differs from that described in -RFC 1035. The origin and current domain revert to the values they were prior -to the $INCLUDE once the file has been read. - -6.3.5.3 The $TTL Directive - -Syntax: $TTL < default-ttl > [ < comment > ] - -Set the default Time To Live (TTL) for subsequent records with undefined -TTLs. Valid TTLs are of the range 0-2147483647 seconds. - -$TTL is defined in RFC 2308. - -6.3.6 BIND Master File Extension: the $GENERATE Directive - -$GENERATE - -Syntax: $GENERATE < range > < lhs > < type > < rhs > [ < comment > ] - -$GENERATE is used to create a series of resource records that only differ -from each other by an iterator. $GENERATE can be used to easily generate the -sets of records required to support sub /24 reverse delegations described in -RFC 2317: Classless IN-ADDR.ARPA delegation. - -$ORIGIN 0.0.192.IN-ADDR.ARPA. -$GENERATE 1-2 0 NS SERVER$.EXAMPLE. -$GENERATE 1-127 $ CNAME $.0 - -is equivalent to - -0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE. -0.0.0.192.IN-ADDR.ARPA NS SERVER2.EXAMPLE. -1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA -2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA -... -127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA -. - - - - range This can be one of two forms: start-stop or start-stop/step. If the - first form is used then step is set to 1. All of start, stop and - step must be positive. - - lhs lhs describes the owner name of the resource records to be created. - Any single $ symbols within the lhs side are replaced by the - iterator value. To get a $ in the output use a double $, e.g. $$. - If the lhs is not absolute, the current $ORIGIN is appended to the - name. - - type At present the only supported types are PTR, CNAME and NS. - - rhs rhs is a domain name. It is processed similarly to lhs. - -The $GENERATE directive is a BIND extension and not part of the standard -zone file format. It is not yet implemented in BIND 9. - - - ------------------------------------------------------------------------ - - Section 7. BIND 9 Security Considerations - - 7.1 Access Control Lists - -Access Control Lists (ACLs), are address match lists that you can set up and -nickname for future use in allow-query, allow-recursion, blackhole, -allow-transfer, etc. - -Using ACLs allows you to have finer control over who can access your -nameserver, without cluttering up your config files with huge lists of IP -addresses. - -It is a good idea to use ACLs, and to control access to your server. -Limiting access to your server by outside parties can help prevent spoofing -and DoS attacks against your server. - -Here is an example of how to properly apply ACLs: - - -// Set up an ACL named "bogusnets" that will block RFC1918 space, -// which is commonly used in spoofing attacks. - -acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; -10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; - -// Set up an ACL called our-nets. Replace this with the real IP numbers. - -acl our-nets { x.x.x.x/24; x.x.x.x/21; }; - -options { - ... - ... - allow-query { our-nets; }; - allow-recursion { our-nets; }; - ... - blackhole { bogusnets; }; - ... -}; -zone "example.com" { - type master; - file "m/example.com"; - allow-query { any; }; -}; - -This allows recursive queries of the server from the outside unless -recursion has been previously disabled. - -For more information on how to use ACLs to protect your server, see the -AUSCERT advisory at -ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos - - 7.2 chroot and setuid (for UNIX servers) - -On UNIX servers, it is possible to run BIND in a chrooted environment ( -chroot() ) by specifying the "-t" option. This can help improve system -security by placing BIND in a "sandbox," which will limit the damage done if -a server is compromised. - -Another useful feature in the UNIX version of BIND is the ability to run the -daemon as a nonprivileged user (-u user). We suggest running as a -nonprivileged user when using the chroot feature. - -Here is an example command line to load BIND in a chroot() sandbox, -/var/named, and to run named setuid to user 202: - -/usr/local/bin/named -u 202 -t /var/named - - 7.2.1 The chroot Environment - -In order for a chroot() environment to work properly in a particular -directory (for example, /var/named), you will need to set up an environment -that includes everything BIND needs to run. From BIND's point of view, -/var/named is the root of the filesystem. You will need /dev/null, and any -library directories and files that BIND needs to run on your system. Please -consult your operating system's instructions if you need help figuring out -which library files you need to copy over to the chroot() sandbox. - -If you are running an operating system that supports static binaries, you -can also compile BIND statically and avoid the need to copy system libraries -over to your chroot() sandbox. - - 7.2.2 Using the setuid Function - -Prior to running the named daemon, use the touch utility (to change file -access and modification times) or the chown utility (to set the user id -and/or group id) on files to which you want BIND to write. - - 7.3 Dynamic Updates - -Access to the dynamic update facility should be strictly limited. In earlier -versions of BIND the only way to do this was based on the IP address of the -host requesting the update. BIND 9 also supports authenticating -updates cryptographically by means of transaction signatures (TSIG). The use -of TSIG is strongly recommended. - -Some sites choose to keep all dynamically updated DNS data in a subdomain -and delegate that subdomain to a separate zone. This way, the top-level zone -containing critical data such as the IP addresses of public web and mail -servers need not allow dynamic update at all. - - ------------------------------------------------------------------------ - - Section 8. Troubleshooting - - 8.1 Common Problems - - 8.1.1 It's not working; how can I figure out what's wrong? - -The best solution to solving installation and configuration issues is to -take preventative measures by setting up logging files beforehand. (See the -sample configurations) in Section 3. The log files provide a source of hints -and information that can be used to figure out what went wrong and how to -fix the problem. - - 8.2 Incrementing and Changing the Serial Number - -Zone serial numbers are just numbers--they aren't date related. A lot of -people set them to a number that represents a date, usually of the form -YYYYMMDDRR. A number of people have been testing these numbers for Y2K -compliance and have set the number to the year 2000 to see if it will work. -They then try to restore the old serial number. This will cause problems -because serial numbers are used to indicate that a zone has been updated. If -the serial number on the slave server is lower than the serial number on the -master, the slave server will attempt to update its copy of the zone. - -Setting the serial number to a lower number on the master server than the -slave server means that the slave will not perform updates to its copy of -the zone. - -The solution to this is to add 2147483647 (2^31-1) to the number, reload the -zone and make sure all slaves have updated to the new zone serial number, -then reset the number to what you want it to be, and reload the zone again. - - 8.3 Where Can I Get Help? - -The Internet Software Consortium (ISC) offers a wide range of support and -service agreements for BIND and DHCP servers. Four levels of premium support -are available and each level includes support for all ISC programs, -significant discounts on products and training, and a recognized priority on -bug fixes and non-funded feature requests. In addition, ISC offers a -standard support agreement package which includes services ranging from bug -fix announcements to remote support. It also includes training in BIND and -DHCP. - -To discuss arrangements for support, contact info@isc.org or visit the ISC -web page at -http://www.isc.org/services/support/ to read more. - - ------------------------------------------------------------------------ - -APPENDICES - -Acknowledgements - -A Brief History of the DNS and BIND - -Although the "official" beginning of the Domain Name System occurred in 1984 -with the publication of RFC 920, the core of the new system was described in -1983 in RFCs 882 and 883. From 1984 to 1987, the ARPAnet (the precursor to -today's Internet) became a testbed of experimentation for developing the new -naming/addressing scheme in an rapidly expanding, operational network -environment. New RFCs were written and published in 1987 that modified the -original documents to incorporate improvements based on the working model. -RFC 1034, "Domain Names-Concepts and Facilities," and RFC 1035, "Domain -Names-Implementation and Specification" were published and became the -standards upon which all DNS implementations are built. - -The first working domain name server, called "Jeeves," was written in -1983-84 by Paul Mockapetris for operation on DEC Tops-20 machines located at -the University of Southern California's Information Sciences Institute -(USC-ISI) and SRI International's Network Information Center (SRI-NIC). A -DNS server for Unix machines, the Berkeley Internet Name Domain (BIND) -package, was written soon after by a group of graduate students at the -University of California at Berkeley under a grant from the US Defense -Advanced Research Projects Administration (DARPA). Versions of BIND through -4.8.3 were maintained by the Computer Systems Research Group (CSRG) at UC -Berkeley. Douglas Terry, Mark Painter, David Riggle and Songnian Zhou made -up the initial BIND project team. After that, additional work on the -software package was done by Ralph Campbell. Kevin Dunlap, a Digital -Equipment Corporation employee on loan to the CSRG, worked on BIND for 2 -years, from 1985 to 1987. Many other people also contributed to BIND -development during that time: Doug Kingston, Craig Partridge, Smoot -Carl-Mitchell, Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was -subsequently handled by Mike Karels and O. Kure. - -BIND versions 4.9 and 4.9.1 were released by Digital Equipment Corporation -(now Compaq Computer Corporation). Paul Vixie, then a DEC employee, became -BIND's primary caretaker. Paul was assisted by Phil Almquist, Robert Elz, -Alan Barrett, Paul Albitz, Bryan Beecher, Andrew Partan, Andy Cherenson, Tom -Limoncelli, Berthold Paffrath, Fuat Baran, Anant Kumar, Art Harkin, Win -Treese, Don Lewis, Christophe Wolfhugel, and others. - -BIND Version 4.9.2 was sponsored by Vixie Enterprises. Paul Vixie became -BIND's principal architect/programmer. - -BIND versions from 4.9.3 onward have been developed and maintained by the -Internet Software Consortium with support being provided by ISC's sponsors. -As co-architects/programmers, Bob Halley and Paul Vixie released the first -production-ready version of BIND version 8 in May 1997. - -BIND development work is made possible today by the sponsorship of several -corporations, and by the tireless work efforts of numerous individuals. - -Historical DNS Information - -Classes of Resource Records - -HS = hesiod - -The hesiod class is an information service developed by MIT's Project -Athena. It is used to share information about various systems databases, -such as users, groups, printers and so on. The keyword hs is a synonym for -hesiod. - -CH = chaos - -The chaos class is used to specify zone data for the MIT-developed CHAOSnet, -a LAN protocol created in the mid-1970s. - -General DNS Reference Information - -IPv6 addresses (A6) - -IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces -which were introduced in the DNS to facilitate scalable Internet routing. -There are three types of addresses: Unicast, an identifier for a single -interface; Anycast, an identifier for a set of interfaces; and Multicast, -an identifier for a set of interfaces. Here we describe the global Unicast -address scheme. For more information, see RFC 2374. - -The aggregatable global Unicast address format is as follows: - - - - 3 13 8 24 16 64 bits - FP TLA ID RES NLA ID SLA ID Interface ID - <-- Public Topology --> - <-Site Topology-> - - <- Interface Identifier -> - -Where - - FP = Format Prefix (001) - TLA ID = Top-Level Aggregation Identifier - RES = Reserved for future use - NLA ID = Next-Level Aggregation Identifier - SLA ID = Site-Level Aggregation Identifier - INTERFACE ID = Interface Identifier - -The Public Topology is provided by the upstream provider or ISP, and -(roughly) corresponds to the IPv4 network section of the address range. The -Site Topology is where you can subnet this space, much the same as -subnetting an IPv4 /16 network into /24 subnets. The Interface -Identifier is the address of an individual interface on a given network. -(With IPv6, addresses belong to interfaces rather than machines.) - -The subnetting capability of IPv6 is much more flexible than that of IPv4: -subnetting can now be carried out on bit boundaries, in much the same way as -Classless InterDomain Routing (CIDR). - -The internal structure of the Public Topology for an A6 global unicast -address consists of: - - - - 3 13 8 24 - FP TLA ID RES NLA ID - -A 3 bit FP (Format Prefix) of 001 indicates this is a global Unicast -address. FP lengths for other types of addresses may vary. - -13 TLA (Top Level Aggregator) bits give the prefix of your top-level IP -backbone carrier. - -8 Reserved bits - -24 bits for Next Level Aggregators. This allows organizations with a TLA to -hand out portions of their IP space to client organizations, so that the -client can then split up the network further by filling in more NLA bits, -and hand out IPv6 prefixes to their clients, and so forth. - -There is no particular structure for the Site topology section. -Organizations can allocate these bits in any way they desire. - -The Interface Identifier must be unique on that network. On ethernet -networks, one way to ensure this is to set the address to the first three -bytes of the hardware address, "FFFE", then the last three bytes of the -hardware address. The lowest significant bit of the first byte should then -be complemented. Addresses are written as 32-bit blocks separated with a -colon, and leading zeros of a block may be omitted, for example: - -3ffe:8050:201:9:a00:20ff:fe81:2b32 - -IPv6 address specifications are likely to contain long strings of zeros, so -the architects have included a shorthand for specifying them. The double -colon ('::') indicates the longest possible string of zeros that can fit, -and can be used only once in an address. - -Bibliography (and Suggested Reading) - -Request for Comments (RFCs) - -Specification documents for the Internet protocol suite, including the DNS, -are published as part of the Request for Comments (RFCs) series of technical -notes. The standards themselves are defined by the Internet Engineering Task -Force (IETF) and the Internet Engineering Steering Group (IESG). RFCs can be -obtained online via FTP at -ftp://www.isi.edu/in-notes/RFCxxx.txt (where xxx is the number of the RFC). -RFCs are also available via the Web at http://www.ietf.org/rfc/. - -Standards - -RFC974. Partridge, C. Mail Routing and the Domain System. January 1986. - -RFC1034. Mockapetris, P.V. Domain Names - Concepts and Facilities. P.V. -November 1987. - -RFC1035. Mockapetris, P. V. Domain Names - Implementation and Specification -. November 1987. - -Proposed Standards - -RFC2181. Elz, R., R. Bush. Clarifications to the DNS Specification. July -1997. - -RFC2308. Andrews, M. Negative Caching of DNS Queries. March 1998. - -RFC1995. Ohta, M. Incremental Zone Transfer in DNS. August 1996. - -RFC1996. Vixie, P. A Mechanism for Prompt Notification of Zone Changes. -August 1996. - -RFC2136. Vixie, P., S. Thomson, Y. Rekhter, J. Bound. Dynamic Updates in the -Domain Name System. April 1997. - -RFC2845. Vixie, P., O. Gudmundsson, D. Eastlake 3rd, B. Wellington. Secret -Key Transaction Authentication for DNS (TSIG). May 2000. - -Proposed Standards Still Under Development - -Note: the following list of RFCs are undergoing major revision by the IETF. - -RFC1886. Thomson, S., C. Huitema. DNS Extensions to support IP version 6. -S. December 1995. - -RFC2065. Eastlake, 3rd, D., C. Kaufman. Domain Name System Security -Extensions. January 1997. - -RFC2137. Eastlake, 3rd, D. Secure Domain Name System Dynamic Update. April -1997. - -Other Important RFCs About DNS Implementation - -RFC1535. Gavron, E. A Security Problem and Proposed Correction With Widely -Deployed DNS Software. October 1993. - -RFC1536. Kumar, A., J. Postel, C. Neuman, P. Danzig, S. Miller. Common DNS -Implementation Errors and Suggested Fixes. October 1993. - -RFC1982. Elz, R., R. Bush. Serial Number Arithmetic. August 1996. - -Resource Record Types - -RFC1183. Everhart, C.F., L. A. Mamakos, R. Ullmann, P. Mockapetris. New DNS -RR Definitions. October 1990. - -RFC1706. Manning, B., R. Colella. DNS NSAP Resource Records. October 1994. - -RFC2168. Daniel, R., M. Mealling. Resolution of Uniform Resource Identifiers -using the Domain Name System. June 1997. - -RFC1876. Davis, C., P. Vixie, T. Goodwin, I. Dickinson. A Means for -Expressing Location Information in the Domain Name System. January 1996. - -RFC2052. Gulbrandsen, A., P. Vixie. A DNS RR for Specifying the Location of -Services. October 1996. - -RFC2163. Allocchio, A. U sing the Internet DNS to Distribute MIXER -Conformant Global Address Mapping. January 1998. - -RFC2230. Atkinson, R. Key Exchange Delegation Record for the DNS. October -1997. - -DNS and the Internet - -RFC1101. Mockapetris, P. V. DNS Encoding of Network Names and Other Types. -April 1989. - -RFC1123. Braden, R. Requirements for Internet Hosts - Application and -Support. October 1989. - -RFC1591. Postel, J. D omain Name System Structure and Delegation. March -1994. - -RFC2317. Eidnes, H., G. de Groot, P. Vixie. Classless IN-ADDR.ARPA -Delegation. March 1998. - -DNS Operations - -RFC1537. Beertema, P. Common DNS Data File Configuration Errors. October -1993. - -RFC1912. Barr, D. Common DNS Operational and Configuration Errors. February -1996. - -RFC1912. Barr, D. Common DNS Operational and Configuration Errors. February -1996. - -RFC2010. Manning, B., P. Vixie. Operational Criteria for Root Name Servers. -October 1996. - -RFC2219. Hamilton, M., R. Wright. Use of DNS Aliases for Network Services. -October 1997. - -Other DNS-related RFCs - -Note: the following list of RFCs, although DNS-related, are not concerned -with implementing software. - -RFC1464. Rosenbaum, R. Using the Domain Name System To Store Arbitrary -String Attributes. May 1993. - -RFC1713. Romao, A. Tools for DNS Debugging. November 1994. - -RFC1794. Brisco, T. DNS Support for Load Balancing. April 1995. - -RFC2240. Vaughan, O. A Legal Basis for Domain Name Allocation. -November1997. - -RFC2345. Klensin, J., T. Wolf, G. Oglesby. Domain Names and Company Name -Retrieval. May 1998. - -RFC2352. Vaughan, O. A Convention For Using Legal Names as Domain Names. -May 1998. - -Obsolete and Unimplemented Experimental RRs - -RFC1712. Farrell, C., M. Schulze, S. Pleitner, D. Baldoni. DNS Encoding of -Geographical Location. November 1994. - -Internet Drafts - -Internet Drafts (IDs) are rough-draft working documents of the Internet -Engineering Task Force. They are, in essence, RFCs in the preliminary stages -of development. Implementors are cautioned not to regard IDs as archival, -and they should not be quoted or cited in any formal documents unless -accompanied by the disclaimer that they are "works in progress." IDs have a -lifespan of six months after which they are deleted unless updated by their -authors. - -Other BIND Documents - -Albitz, Paul and Cricket Liu. 1998. DNS and BIND. Sebastopol, CA: O'Reilly -and Associates. - - ------------------------------------------------------------------------ -