BIND 9 Administrator Reference Manual Abstract This manual is reproduced with permission from the Internet Software Consortium. This manual describes the Domain Name System. The DNS 9.2.3 product available on the NonStop server consists of a subset of the software described in the BIND 9 Administrator Manual; refer to the DNS Configuration and Management Manual for limitations and features of the ported product. Product Version NA Supported Release Version Updates (RVUs) This publication supports G06.
Document History Part Number Product Version 529540-001 NA Published December 2004 (C) Copyright 2000, 2001 Internet Software Consortium. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
BIND 9 Administrator Reference Manual
BIND 9 Administrator Reference Manual Copyright © 2000, 2001 by Internet Software Consortium
Table of Contents 1. Introduction............................................................................................................................................9 1.1. Scope of Document .....................................................................................................................9 1.2. Organization of This Document..................................................................................................9 1.3. Conventions Used in This Document.......................
4.4. TSIG..........................................................................................................................................30 4.4.1. Generate Shared Keys for Each Pair of Hosts ..............................................................30 4.4.1.1. Automatic Generation......................................................................................30 4.4.1.2. Manual Generation...........................................................................................31 4.4.2.
6.2.4. controls Statement Definition and Usage ....................................................................49 6.2.5. include Statement Grammar ........................................................................................50 6.2.6. include Statement Definition and Usage......................................................................50 6.2.7. key Statement Grammar...............................................................................................50 6.2.8.
6.3. Zone File ...................................................................................................................................89 6.3.1. Types of Resource Records and When to Use Them ...................................................89 6.3.1.1. Resource Records.............................................................................................89 6.3.1.2. Textual expression of RRs ...............................................................................92 6.3.2.
Chapter 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 domain name server for a number of operating systems.
Chapter 1. Introduction literal user input Fixed Width Bold program output Fixed Width The following conventions are used in descriptions of the BIND configuration file: To describe: We use the style: keywords Fixed Width variables Fixed Width Optional input [Text is enclosed in square brackets] 1.4.
Chapter 1. Introduction For example, a domain name for a host at the company Example, Inc. could be mail.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. For administrative purposes, the name space is partitioned into areas called zones, each starting at a node and extending down to the leaf nodes or to nodes where other zones start.
Chapter 1. Introduction zone. To make the DNS tolerant of server and network failures, most zones have two or more authoritative servers. Responses from authoritative servers have the "authoritative answer" (AA) bit set in the response packets. This makes them easy to identify when debugging DNS configurations using tools like dig (Section 3.4.1.1). 1.4.4.1.
Chapter 1. Introduction 1.4.5. Caching Name Servers The resolver libraries provided by most operating systems are stub resolvers, meaning that they are not capable of performing the full DNS resolution process by themselves by talking directly to the authoritative servers. Instead, they rely on a local name server to perform the resolution on their behalf. Such a server is called a recursive name server; it performs recursive lookups for local clients.
Chapter 1.
Chapter 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.
Chapter 2. BIND Resource Requirements 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.
Chapter 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.
Chapter 3. Nameserver Configuration // 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.
Chapter 3. Nameserver Configuration 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, see RRset Ordering.
Chapter 3. Nameserver Configuration dig [@server] domain [query-type] [query-class] [+query-option] [-dig-option] [%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.
Chapter 3. Nameserver Configuration 3.4.1.2. Administrative Tools Administrative tools play an integral part in the management of a server. named-checkconf The named-checkconf program checks the syntax of a named.conf file. named-checkconf [-t directory] [filename] named-checkzone The named-checkzone program checks a master file for syntax and consistency.
Chapter 3. Nameserver Configuration stats Write server statistics to the statistics file. querylog Toggle query logging. Query logging can also be enabled by explictly directing the queries category to a channel in the logging section of named.conf. dumpdb Dump the server’s caches to the dump file. stop Stop the server, making sure any recent changes made through dynamic update or IXFR are first saved to the master files of the updated zones. halt Stop the server immediately.
Chapter 3. Nameserver Configuration alternate location can be specified with the -c option. If the configuration file is not found, rndc will also look in /etc/rndc.key (or whatever sysconfdir was defined when the BIND build was configured). The rndc.key file is generated by running rndc-confgen -a as described in Section 6.2.4. The format of the configuration file is similar to that of named.conf, but limited to only four statements, the options, key, server and include statements.
Chapter 3. Nameserver Configuration }; and it had an identical key statement for rndc_key. Running the rndc-confgen program will conveniently create a rndc.conf file for you, and also display the corresponding controls statement that you need to add to named.conf. Alternatively, you can run rndc-confgen -a to set up a rndc.key file and not modify named.conf at all. 3.4.2. Signals Certain UNIX signals cause the name server to take specific actions, as described in the following table.
Chapter 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.
Chapter 4. Advanced Concepts 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 Proposed Standards. When acting as a master, BIND 9 supports IXFR for those zones where the necessary change history information is available.
Chapter 4. Advanced Concepts 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.
Chapter 4. Advanced Concepts 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 { nal servers bastion-ips-go-here; }; allow-transfer { none; }; transfer (no one) allow-query { internals; externals; }; allow-recursion { internals; }; ... ... }; zone "site1.example.com" { type master; file "m/site1.example.
Chapter 4. Advanced Concepts 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 { ... ...
Chapter 4. Advanced Concepts 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.
Chapter 4. Advanced Concepts 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.
Chapter 4. Advanced Concepts 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 request 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 request messages to host1. 4.4.5.
Chapter 4. Advanced Concepts 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).
Chapter 4. Advanced Concepts 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.
Chapter 4. Advanced Concepts 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.
Chapter 4. Advanced Concepts 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.
Chapter 4. Advanced Concepts 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 3600 IN A6 0 3ffe:8050:201:1860:42::1 4.8.2.1.
Chapter 4. Advanced Concepts ns0 ns1 14400 14400 IN IN A6 A 0 3ffe:8050:201:1860:42::1 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.
Chapter 4. Advanced Concepts host $ORIGIN example.net. cust1 ipv6net $ORIGIN example2.net. subnet5 ipv6net2 IN IN A6 A6 64 64 ::1234:5678:1212:5675 cust1.example.net. ::1234:5678:1212:5675 subnet5.example2.net. IN IN A6 A6 48 0 0:0:0:dddd:: ipv6net.example.net. aa:bb:cccc:: IN IN A6 A6 48 0 0:0:0:1:: ipv6net2.example2.net. 6666:5555:4:: This sets up forward lookups. To handle the reverse lookups, the provider example.net would have: $ORIGIN \[x00aa00bbcccc/48].ip6.arpa.
Chapter 4.
Chapter 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.
Chapter 5.
Chapter 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.
Chapter 6. BIND 9 Configuration Reference key_id key_list A domain_name representing the name of a shared key, to be used for transaction security. A list of one or more key_ids, separated by semicolons and ending with a semicolon. number path_name A non-negative 32 bit unsigned integer (i.e., a number between 0 and 4294967295, inclusive). Its acceptable value might further be limited by the context in which it is used. A quoted string which will be used as a pathname, such as zones/master/my.test.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference localnets Matches any host on an IPv4 network for which the system has an interface. The localhost and localnets ACLs do not currently support IPv6 (that is, localhost does not match the host’s IPv6 addresses, and localnets does not match the host’s attached IPv6 networks) due to the lack of a standard method of determining the complete set of local IPv6 addresses for a host. 6.2.3.
Chapter 6. BIND 9 Configuration Reference file rndc.key in /etc (or whatever sysconfdir was specified as when BIND was built). To create a rndc.key file, run rndc-confgen -a. The rndc.key feature was created to ease the transition of systems from BIND 8, which did not have digital signatures on its command channel messages and thus did not have a keys clause.
Chapter 6. BIND 9 Configuration Reference 6.2.8. key Statement Definition and Usage The key statement defines a shared secret key for use with TSIG, see Section 4.4. The key statement can occur at the top level of the configuration file or inside a view statement. Keys defined in top-level key statements can be used in all views. Keys intended for use in a controls statement (see Section 6.2.4) must be defined at the top level.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference are rolled as described above and a new one begun. If there is no versions option, no more data will be written to the log until some out-of-band mechanism removes or truncates the log to less than the maximum size. The default behavior is not to limit the size of the file. Example usage of the size and versions options: channel "an_example_channel" { file "example.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference [ listenon { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ] [ view view_name; ] [ search { domain_name ; [ domain_name ; ... ] }; ] [ ndots number; ] }; 6.2.12. lwres Statement Definition and Usage The lwres statement configures the name server to also act as a lightweight resolver server, see Section 5.2. There may be be multiple lwres statements configuring lightweight resolver servers with different properties.
Chapter 6.
Chapter 6. BIND 9 Configuration Reference [ alsonotify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ] [ 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 ; ...
Chapter 6. BIND 9 Configuration Reference 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 ‘.
Chapter 6. BIND 9 Configuration Reference pid-file The pathname of the file the server writes its process ID in. If not specified, the default is /var/run/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 when instructed to do so using rndc stats. If not specified, the default is named.stats in the server’s current directory. The format of the file is described in Section 6.2.14.
Chapter 6. BIND 9 Configuration Reference 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 view and zone statements, in which case it overrides the global dialup option. If the zone is a master zone then the server will send out a NOTIFY request to all the slaves.
Chapter 6. BIND 9 Configuration Reference minimal-responses If yes, then when generating responses the server will only add records to the authority and additional data sections when they are required (e.g. delegations, negative responses). This may improve the performance of the server. The default is 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.
Chapter 6. BIND 9 Configuration Reference use-id-pool This option is obsolete. BIND 9 always allocates query IDs from a pool. zone-statistics If yes, the server will, by default, collect statistical data on all zones in the server. These statistics may be accessed using rndc stats, which will dump them to the file listed in the statistics-file. See also Section 6.2.14.15. use-ixfr This option is obsolete.
Chapter 6. BIND 9 Configuration Reference mail.example.net will be provided as well, if known. Setting these options to no disables this behavior. These options are intended for use in authoritative-only servers, or in authoritative-only views. Attempts to set them to no without also specifying recursion no; will cause the server to ignore the options and log a warning message.
Chapter 6. BIND 9 Configuration Reference 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 Section 6.2.21. 6.2.14.3. Access Control Access to the server can be restricted based on the IP address of the requesting system. See Section 6.1.
Chapter 6. BIND 9 Configuration Reference 6.2.14.4. 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.
Chapter 6. BIND 9 Configuration Reference 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: The address specified in the query-source option is used for both UDP and TCP queries, but the port applies only to UDP queries. TCP queries always use a random unprivileged port. 6.2.14.6.
Chapter 6. BIND 9 Configuration Reference serial-query-rate 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. To limit the amount of bandwidth used, BIND 9 limits the rate at which queries are sent. The value of the serial-query-rate option, an integer, is the maximum number of queries sent per second. The default is 20.
Chapter 6. BIND 9 Configuration Reference transfer-source transfer-source determines which local address will be bound to IPv4 TCP connections used to fetch zones transferred inbound by the server. It also determines the source IPv4 address, and optionally the UDP port, used for the refresh queries and forwarded dynamic updates. If not set, it defaults to a system controlled value which will usually be the address of the interface "closest to" the remote end.
Chapter 6. BIND 9 Configuration Reference datasize The maximum amount of data memory the server may use. The default is default. This is a hard limit on server memory usage. If the server attempts to allocate memory in excess of this limit, the allocation will fail, which may in turn leave the server unable to perform DNS service.
Chapter 6. BIND 9 Configuration Reference The default is unlimited, meaning that records are purged from the cache only when their TTLs expire. 6.2.14.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 as dialup whenever this interval expires.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 6.2.14.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. The rrset-order statement permits configuration of the ordering of the records in a multiple record response. See also the sortlist statement, Section 6.2.14.11.
Chapter 6. BIND 9 Configuration Reference for forward lookups and "nibble labels" in the ip6.int domain for reverse lookups, but do not support RFC2874-style lookups (using A6 records and binary labels in the ip6.arpa domain). For those who wish to continue to use such stub resolvers rather than switching to the BIND 9 lightweight resolver, BIND 9 provides a way to automatically convert RFC1886-style lookups into RFC2874-style lookups and return the results as "synthetic" AAAA and PTR records.
Chapter 6. BIND 9 Configuration Reference Note: Not yet implemented in BIND9. sig-validity-interval Specifies the number of days into the future when DNSSEC signatures automatically generated as a result of dynamic updates (Section 4.1) 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.
Chapter 6. BIND 9 Configuration Reference success The number of successful queries made to the server or zone. A successful query is defined as query which returns a NOERROR response other than a referral response. referral The number of queries which resulted in referral responses. nxrrset The number of queries which resulted in NOERROR responses with no data. nxdomain The number of queries which resulted in NXDOMAIN responses.
Chapter 6. BIND 9 Configuration Reference 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 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.
Chapter 6. BIND 9 Configuration Reference string number number number string ; [ string number number number string ; [...]] }; 6.2.18. trusted-keys Statement Definition and Usage The trusted-keys statement defines DNSSEC security roots. DNSSEC is described in Section 4.7. 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 6.2.21. zone Statement Grammar zone zone_name [class] [{ type ( master | slave | hint | stub | forward ) ; [ allow-notify { address_match_list } ; ] [ 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 } ; ] [ alsonotify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ...
Chapter 6. BIND 9 Configuration Reference 6.2.22. zone Statement Definition and Usage 6.2.22.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 of master servers that the slave contacts to update its copy of the zone.
Chapter 6. BIND 9 Configuration Reference 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 feature specific to the BIND implementation. Stub zones can be used to eliminate the need for glue NS record in a parent zone at the expense of maintaining a stub zone entry and a set of name server addresses in named.conf.
Chapter 6. BIND 9 Configuration Reference 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 uses a compiled-in default set of root servers hints. Classes other than IN have no built-in defaults hints. 6.2.22.2. Class The zone’s name may optionally be followed by a class.
Chapter 6. BIND 9 Configuration Reference 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 { none; }, which means that no update forwarding will be performed. To enable update forwarding, specify allow-update-forwarding { any; };.
Chapter 6. BIND 9 Configuration Reference 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. 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.
Chapter 6. BIND 9 Configuration Reference zone-statistics If yes, the server will keep statistical information for this zone, which can be dumped to the statistics-file defined in the server options. sig-validity-interval See the description of sig-validity-interval in Section 6.2.14.14. transfer-source See the description of transfer-source in Section 6.2.14.6 transfer-source-v6 See the description of transfer-source-v6 in Section 6.2.14.6 notify-source See the description of notify-source in Section 6.2.
Chapter 6. BIND 9 Configuration Reference 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 message has successfully matched a rule, the operation is immediately granted or denied and no further rules are examined.
Chapter 6. BIND 9 Configuration Reference 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 Section 6.2.14.11 and Section 6.2.14.12.
Chapter 6. BIND 9 Configuration Reference LOC MX (x) for storing GPS info. See RFC 1876. Experimental. identifies a mail exchange for the domain. See RFC 974 for details. NAPTR name authority pointer. NSAP a network service access point. NS the authoritative nameserver for the domain. NXT used in DNSSEC to securely indicate that RRs with an owner name in a 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.
Chapter 6. BIND 9 Configuration Reference A A6 CNAME for the IN class, a 32 bit IP address. maps a domain name to an IPv6 address, with a provision for indirection for leading "prefix" bits. a domain name. DNAME provides alternate naming to an entire subtree of the domain name 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference 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.
Chapter 6. BIND 9 Configuration Reference $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.
Chapter 6. BIND 9 Configuration Reference $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.
Chapter 6.
Chapter 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-notify, 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.
Chapter 7. BIND 9 Security Considerations 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 ).
Chapter 7. BIND 9 Security Considerations can be trivially attacked by sending the update to the slave, which will forward it to the master with its own source IP address causing the master to approve it without question. For these reasons, we strongly recommend that updates be cryptographically authenticated by means of transaction signatures (TSIG). That is, the allow-update option should list only TSIG key names, not IP addresses or network prefixes.
Chapter 7.
Chapter 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. 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.
Chapter 8. Troubleshooting To discuss arrangements for support, contact info@isc.org (mailto:info@isc.org) or visit the ISC web page at http://www.isc.org/services/support/ to read more.
Appendix A. Appendices A.1. Acknowledgements A.1.1. 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.
Appendix A. Appendices 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. A.2. Historical DNS Information A.2.1. Classes of Resource Records A.2.1.1. HS = hesiod The [hesiod] class is an information service developed by MIT’s Project Athena.
Appendix A.
Appendix A. Appendices 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.
Appendix A. Appendices [RFC1035] P. V. Mockapetris, Domain Names — Implementation and Specification, November 1987. Proposed Standards [RFC2181] R., R. Bush Elz, Clarifications to the DNS Specification, July 1997. [RFC2308] M. Andrews, Negative Caching of DNS Queries, March 1998. [RFC1995] M. Ohta, Incremental Zone Transfer in DNS, August 1996. [RFC1996] P. Vixie, A Mechanism for Prompt Notification of Zone Changes, August 1996. [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J.
Appendix A. Appendices Resource Record Types [RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris, New DNS RR Definitions, October 1990. [RFC1706] B. Manning and R. Colella, DNS NSAP Resource Records, October 1994. [RFC2168] R. Daniel and M. Mealling, Resolution of Uniform Resource Identifiers using the Domain Name System, June 1997. [RFC1876] C. Davis, P. Vixie, T., and I. Dickinson, A Means for Expressing Location Information in the Domain Name System, January 1996. [RFC2052] A.
Appendix A. Appendices [RFC2010] B. Manning and P. Vixie, Operational Criteria for Root Name Servers., October 1996. [RFC2219] M. Hamilton and R. Wright, Use of DNS Aliases for Network Services., October 1997. Other DNS-related RFCs [RFC1464] R. Rosenbaum, Using the Domain Name System To Store Arbitrary String Attributes, May 1993. [RFC1713] A. Romao, Tools for DNS Debugging, November 1994. [RFC1794] T. Brisco, DNS Support for Load Balancing, April 1995. [RFC2240] O.
Appendix A. Appendices Bibliography Paul Albitz and Cricket Liu, DNS and BIND, 1998.
