diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 2525ee0e82..9de9e39805 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + BIND 9 Administrator Reference Manual @@ -34,7 +34,7 @@ BIND version 9 software package for system administrators. - This version of the manual corresponds to BIND version 9.2. + This version of the manual corresponds to BIND version 9.3. Organization of This Document @@ -140,8 +140,10 @@ used by Internet applications. Clients look up information in the DNS by calling a resolver library, which sends queries to one or more name servers and interprets the responses. -The BIND 9 software distribution contains both a -name server and a resolver library. +The BIND 9 software distribution contains a +name server, named, and two resolver +libraries, liblwres and libbind. + Domains and Domain Names @@ -158,8 +160,8 @@ domain. For example, a domain name for a host at the company Example, Inc. could be -mail.example.net, -were com is the +mail.example.com, +where com is the top level domain to which ourhost.example.com belongs, example is @@ -193,7 +195,7 @@ and a domain. 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 a name server has complete information and over which +tree for which a name 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 is marked by one or more @@ -374,7 +376,7 @@ 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 +BIND 9 is fully multithreaded, allowing full utilization of multiprocessor systems for installations that need it. CPU Requirements CPU requirements for BIND 9 range from i486-class machines @@ -389,77 +391,53 @@ option can be used 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 +to determine this for a given installation is to watch the name server 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. +fast as they are being inserted. -Nameserver Intensive Environment Issues -For nameserver intensive environments, there are two alternative +Name Server Intensive Environment Issues +For name server 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 +any second-level internal name servers query a main name server, 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. +is to set up second-level internal name servers 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. -Supported Operating Systems -ISC BIND 9 compiles and runs on the following operating -systems: - - - IBM AIX 4.3 - - - Compaq Digital/Tru64 UNIX 4.0D - - - Compaq Digital/Tru64 UNIX 5 (with IPv6 EAK) - - - HP HP-UX 11 - - - IRIX64 6.5 - - - Sun Solaris 2.6, 7, 8 - - - NetBSD 1.5 (with unproven-pthreads 0.17) - - - FreeBSD 3.4-STABLE, 3.5, 4.0, 4.1 - - - Red Hat Linux 6.0, 6.1, 6.2, 7.0 - - - - +as none of the name servers share their cached data. - - Nameserver Configuration +Supported Operating Systems +ISC BIND 9 compiles and runs on a large number +of Unix-like operating system and on Windows NT / 2000. For an up-to-date +list of supported systems, see the README file in the top level directory +of the BIND 9 source distribution. + + + + +Name Server Configuration In this section we provide some suggested configurations along with guidelines for their use. We also address the topic of reasonable option setting. - - Sample Configurations - - A Caching-only Nameserver - The following sample configuration is appropriate for a caching-only + + +Sample Configurations + +A Caching-only Name Server +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. - +from outside clients are refused using the allow-query +option. Alternatively, the same effect could be achieved using suitable +firewall rules. + + // Two corporate subnets we wish to allow queries from. -acl "corpnets" { 192.168.4.0/24; 192.168.7.0/24; }; +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"; }; + allow-query { corpnets; }; }; // Provide a reverse mapping for the loopback address 127.0.0.1 zone "0.0.127.in-addr.arpa" { @@ -468,16 +446,17 @@ zone "0.0.127.in-addr.arpa" { notify no; }; - - - An Authoritative-only Nameserver - This sample configuration is for an authoritative-only server + + + +An Authoritative-only Name Server +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 }; @@ -506,19 +485,22 @@ zone "eng.example.com" { masters { 192.168.4.12; }; }; - - - - Load Balancing - Primitive load balancing can be achieved in DNS using multiple -A records for one name. + + + + +Load Balancing + +A primitive form of load balancing can be achieved in +the DNS by 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: - - + + + @@ -569,113 +551,105 @@ of the time: BIND 9, and only the ordering scheme described above is available. - - - 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, see - . For more information about - notify, see . + +Name Server Operations - - - Nameserver Operations - - Tools for Use With the Nameserver Daemon - There are several indispensable diagnostic, administrative + +Tools for Use With the Name Server 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 +and debugging the name server daemon. We describe several in this section - - 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 + +Diagnostic Tools +The dig, host, and +nslookup programs are all command line tools +for manually querying name servers. They differ in style and +output format. + + + + +dig + +The domain information groper (dig) +is the most versatile and complete of these lookup tools. +It 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. - - 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 + + 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. By default, the utility converts + + + + +host + +The host utility emphasizes simplicity +and ease of use. By default, it converts between host names and Internet addresses, but its functionality can be extended with the use of options. - - - host - -aCdlrTwv - -c class - -N ndots - -t type - -W timeout - -R retries - hostname - server - - For more information and a list of available commands and + + 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 + + + + +nslookup + +nslookup has two modes: interactive +and non-interactive. Interactive mode allows the user to query name servers 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. - - nslookup - -option - - host-to-find - - server - - + + 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 +default name server 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. +of a name server. 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. +optional second argument specifies the host name or address of a name server. Due to its arcane user interface and frequently inconsistent behavior, we do not recommend the use of nslookup. Use dig instead. - - - + + + + @@ -714,7 +688,7 @@ of a server. The remote name daemon control (rndc) program allows the system - administrator to control the operation of a nameserver. + administrator to control the operation of a name server. If you run rndc without any options it will display a usage message as follows: @@ -807,7 +781,8 @@ of a server. In BIND 9.2, rndc supports all the commands of the BIND 8 ndc -utility except ndc start, which was also +utility except ndc start and +ndc restart, which were also not supported in ndc's channel mode. A configuration file is required, since all @@ -845,14 +820,18 @@ host name or address argument and represents the server that will be contacted if no option is provided on the command line. default-key takes -the name of key as its argument, as defined by a key statement. +the name of a key as its argument, as defined by a key statement. default-port specifies the port to which rndc should connect if no port is given on the command line or in a server statement. -The key statement names a key with its -string argument. The string is required by the server to be a valid +The key statement defines an key to be used +by rndc when authenticating with +named. Its syntax is identical to the +key statement in named.conf. +The keyword key is +followed by a key name, which must 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: @@ -861,14 +840,16 @@ 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. -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 the key as defined by the key statement. -The port clause can be used to -specify the port to which rndc should connect -on the given server. +The server statement associates a key +defined using the key statement with a server. +The keyword server is followed by a +host name or address. The server statement +has two clauses: key and port. +The key clause specifies the name of the key +to be used when communicating with this server, and the +port clause can be used to +specify the port rndc should connect +to on the server. A sample minimal configuration file is as follows: @@ -877,7 +858,7 @@ key rndc_key { secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; options { - default-server localhost; + default-server 127.0.0.1; default-key rndc_key; }; @@ -887,8 +868,8 @@ 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 +to connect to 127.0.0.1 port 953 and cause the name server +to reload, if a name server on the local machine were running with following controls statements: controls { @@ -946,15 +927,35 @@ reload the database. - - Advanced Concepts + +Advanced DNS Features + + + +Notify +DNS NOTIFY is a mechanism that allows master +servers 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 zone transfer. + +DNS +For more information about +NOTIFY, see the description of the +notify option in and +the description of the zone option also-notify in +. The NOTIFY +protocol is specified in RFC 1996. + + + - Dynamic Update +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 + Dynamic Update is a method for adding, replacing or deleting + records in a master server by sending it a special form of DNS + messages. The format and meaning of these messages is specified in RFC 2136. Dynamic update is enabled on a zone-by-zone basis, by @@ -983,8 +984,8 @@ reload the database. the complete contents of the updated zone to its zone file. This is not done immediately after each dynamic update, because that would be too slow when a large - zone is updated frequently. Instead, the dump is delayed by 15 - minutes, allowing additional updates to take place. + zone is updated frequently. Instead, the dump is delayed by + up to 15 minutes, allowing additional updates to take place. When a server is restarted after a shutdown or crash, it will replay the journal file to incorporate into the zone any updates that took @@ -1020,7 +1021,7 @@ reload the database. 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 +transfer the entire zone. The IXFR protocol is specified in RFC 1995. See . When acting as a master, BIND 9 @@ -1042,7 +1043,7 @@ of the server statement. Split DNS -Setting up different views, or visibility, of DNS space to +Setting up different views, or visibility, of the 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. @@ -1058,7 +1059,8 @@ 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) +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. @@ -1068,7 +1070,7 @@ 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 +of name servers. 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, @@ -1078,7 +1080,7 @@ 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 +the internal name servers 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 @@ -1099,13 +1101,13 @@ internal hosts. 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. +name servers 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 +name servers 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: @@ -1153,7 +1155,7 @@ options { ... }; -zone "site1.example.com" { // sample slave zone +zone "site1.example.com" { // sample master zone type master; file "m/site1.example.com"; forwarders { }; // do normal iterative @@ -1162,7 +1164,7 @@ zone "site1.example.com" { // sample slave zone allow-transfer { internals; }; }; -zone "site2.example.com" { +zone "site2.example.com" { // sample slave zone type slave; file "s/site2.example.com"; masters { 172.16.72.3; }; @@ -1241,9 +1243,9 @@ 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 . The nsupdate + updates, but IP-based access control is insufficient. + The cryptographic access control provided by TSIG + is far superior. The nsupdate program supports TSIG via the and command line options. @@ -1291,8 +1293,9 @@ 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. +signature. If the signature is successfully verified, the +response is signed by the same key. + 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 @@ -1361,7 +1364,8 @@ allow-update { key host1-host2. ;}; 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, + generated or assigned. BIND 9 + 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 @@ -1441,9 +1445,9 @@ allow-update { key host1-host2. ;}; 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. + It is recommended that zone keys use a cryptographic algorithm + designated as "mandatory to implement" by the IETF; currently + these are RSASHA1 and DSA. The following command will generate a 768 bit DSA key for the child.example zone: @@ -1455,7 +1459,7 @@ allow-update { key host1-host2. ;}; 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). + is DSA, 1 is RSAMD5, 5 is RSASHA1, 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 @@ -1464,9 +1468,10 @@ allow-update { key host1-host2. ;}; 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. + The public keys should be inserted into the zone file by + including the .key files using + $INCLUDE statements. + @@ -1559,8 +1564,8 @@ allow-update { key host1-host2. ;}; Configuring Servers -Unlike in BIND 8, -data is not verified on load in BIND 9, +Unlike BIND 8, +BIND 9 does not verify signatures on load, so zone keys for authoritative zones do not need to be specified in the configuration file. @@ -1588,14 +1593,18 @@ statement, as described later in this document. 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 + "binary label" (also known as "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 complexities of A6 chain following and binary labels, see . Alternatively, applications can link with a stub + resolver that supports A and AAAA records only and rely on the server to + synthesize AAAA recorsd from A6 chains (). + For an overview of the format and structure of IPv6 addresses, see . @@ -1696,7 +1705,7 @@ ns1 14400 IN A 192.168.42.1 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 + deprecated, it is supported for backwards compatibility with existing IPv6 applications. When looking up an address in nibble format, the address @@ -1712,14 +1721,14 @@ $ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int. - Address to Name Lookups Using Bitstring Format + Address to Name Lookups Using Binary Label Format - Bitstring labels can start and end on any bit boundary, + Binary 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: + To replicate the previous example using binary labels: $ORIGIN \[x3ffe805002011860/64].ip6.arpa. @@ -1729,7 +1738,7 @@ $ORIGIN \[x3ffe805002011860/64].ip6.arpa. Using DNAME for Delegation of IPv6 Reverse Addresses - In IPV6, the same host may have many addresses from many + 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 @@ -1798,21 +1807,22 @@ 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. Running a Resolver Daemon + To use the lightweight resolver interface, the system must -run the resolver daemon lwresd. +run the resolver daemon lwresd or a local +name server configured with a lwres statement. + By default, applications using the lightweight resolver library will make UDP requests to the IPv4 loopback address (127.0.0.1) on port 921. The -address can be overriden by lwserver lines in -/etc/resolv.conf. -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 10.1.2.3?" +address can be overridden by lwserver lines in +/etc/resolv.conf. + 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 -caching-only name server that answers requests using the lightweight +caching-only name server that responds to 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. Unless configured otherwise, it uses the name servers listed on @@ -1828,12 +1838,15 @@ be configured to act as a lightweight resolver daemon using the <acronym>BIND</acronym> 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 + +BIND 9 configuration is broadly similar +to BIND 8; however, there are a few new areas +of configuration, such as views. BIND +8 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. @@ -1852,7 +1865,9 @@ defined by the acl statement. address_match_list -A list of one or more ip_addr, ip_prefix, key_id, or acl_name elements, see +A list of one or more ip_addr, +ip_prefix, key_id, +or acl_name elements, see . @@ -1863,7 +1878,8 @@ 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. +255 separated by dots (`.'), such as 123, +45.67 or 89.123.45.67. ip4_addr @@ -1881,9 +1897,9 @@ in dotted_decimal notation. 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 +number is limited to 0 through 65535, with values +below 1024 typically restricted to use by processes running as root. +In some cases an asterisk (`*') character can be used as a placeholder to select a random high-numbered port. @@ -1907,9 +1923,9 @@ 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 +A non-negative 32 bit 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. @@ -1920,18 +1936,17 @@ 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 +or the word default. +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 +which scale by 1024, 1024*1024, and 1024*1024*1024 respectively. +The value must be representable as a 64-bit unsigned integer +(0 to 18446744073709551615, inclusive). +Using unlimited is the best way to safely set a really large number. @@ -1962,71 +1977,73 @@ are restricted to slave and stub zones. 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 +control for various server operations. They are also used in +the listen-on and sortlist +statements. 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) + an IP prefix (in `/' notation) - a key ID, as defined by the key statement + 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" + +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, +for access control, defining listen-on ports, or in a sortlist, 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-notify, allow-query, allow-transfer, -allow-update, allow-update-forwarding +allow-update, allow-update-forwarding, 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 +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. - - Comment Syntax +other 1.2.3.* hosts fall through. + + - 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. + +Comment Syntax - - 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 the C, C++, or shell/perl style. - /* This is a BIND comment as in C */ + +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 @@ -2060,26 +2077,30 @@ comment span multiple lines, each line must use the // pair. 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 + +# 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. - - - - - - Configuration File Grammar + + + + + 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. + + + + + + +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 + statements contain a block of sub-statements, which are also terminated with a semicolon. The following statements are supported: @@ -2214,40 +2235,43 @@ complete set of local IPv6 addresses for a host. <command>controls</command> 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 + channels to be used by system administrators to control the + operation of the name server. These control channels are used by the rndc utility to send commands to - and retrieve non-DNS results from a nameserver. + and retrieve non-DNS results from a name server. An inet control channel is a TCP/IP - socket accessible to the Internet, created at the specified + socket listening 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 + is used. "*" 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 in - ). All commands to the control channel - must be signed by one of its specified keys to - be honored. + keys clauses. Connections to the control + channel are permitted based on the + address_match_list. This is for simple + IP address based filtering only; any key_id + elements of the address_match_list are + ignored. + + + The primary authorization mechanism of the command + channel is the key_list, which contains + a list of key_ids. + Each key_id in + the key_list is authorized to execute + commands over the control channel. + See in + ) for information about + configuring keys in rndc. If no controls statement is present, named will set up a default control channel listening on the loopback address 127.0.0.1 and its IPv6 counterpart ::1. - In this case, and also when the controls statement is present but does not have a keys clause, named will attempt to load the command channel key @@ -2301,12 +2325,12 @@ installed. <command>include</command> Statement Definition and Usage The include statement inserts the - specified file at the point that the include + specified file at the point where 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. + that are readable only by the name server. @@ -2322,7 +2346,10 @@ installed. <command>key</command> Statement Definition and Usage The key statement defines a shared -secret key for use with TSIG, see . +secret key for use with TSIG (see ) +or the command channel +(see ). + The key statement can occur at the top level @@ -2336,7 +2363,8 @@ must be defined at the top level. 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 +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. @@ -2378,7 +2406,7 @@ string. <command>logging</command> Statement Definition and Usage The logging statement configures a wide -variety of logging options for the nameserver. Its channel phrase +variety of logging options for the name server. 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. @@ -2387,8 +2415,8 @@ as many channels and categories as are wanted. If there is no logging logging { - category "unmatched" { "null"; }; - category "default" { "default_syslog"; "default_debug"; }; + category default { default_syslog; default_debug; }; + category unmatched { null; }; }; @@ -2432,7 +2460,7 @@ of the file lamers.log then just before it is opened lamers.log.2, lamers.log.0 is renamed to lamers.log.1, and lamers.log is renamed to lamers.log.0. -You can say versions unlimited; to not limit +You can say versions unlimited to not limit the number of versions. If a size option is associated with the log file, then renaming is only done when the file being opened exceeds the @@ -2452,7 +2480,7 @@ file. Example usage of the size and versions options: -channel "an_example_channel" { +channel an_example_channel { file "example.log" versions 3 size 20m; print-time yes; print-category yes; @@ -2468,7 +2496,7 @@ page. If you have a system which uses a very old version of syslogopenlog() 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 +"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 @@ -2498,7 +2526,7 @@ 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" { +channel specific_debug_level { file "foo"; severity debug 3; }; @@ -2506,7 +2534,7 @@ that specify a specific debug severity, for example: 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. +server's global debug 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 @@ -2525,14 +2553,14 @@ are on: used is described in . -channel "default_syslog" { - syslog daemon; // end to syslog's daemon +channel default_syslog { + syslog daemon; // send to syslog's daemon // facility severity info; // only send priority info // and higher }; -channel "default_debug" { +channel default_debug { file "named.run"; // write to named.run in // the working directory // Note: stderr is used instead @@ -2543,13 +2571,13 @@ channel "default_debug" { // current debug level }; -channel "default_stderr" { // writes to stderr - stderr; +channel default_stderr { + stderr; // writes to stderr severity info; // only send priority info // and higher }; -channel "null" { +channel null { null; // toss anything sent to // this channel }; @@ -2581,23 +2609,23 @@ 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"; }; +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" { +channel my_security_channel { file "my_security_file"; severity info; }; -category "security" { - "my_security_channel"; - "default_syslog"; - "default_debug"; +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"; }; +category xfer-out { null; }; +category notify { null; }; Following are the available categories and brief descriptions of the types of log information they contain. More @@ -2806,6 +2834,7 @@ statement in the named.conf file: notify-source-v6 (ip6_addr | *) port ip_port ; also-notify { ip_addr port ip_port ; ip_addr port ip_port ; ... }; max-ixfr-log-size number; + max-journal-size size_spec; coresize size_spec ; datasize size_spec ; files size_spec ; @@ -2844,9 +2873,7 @@ statement in the named.conf file: 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 +once in a configuration file. If there is no options statement, an options block with each option set to its default will be used. @@ -2857,7 +2884,7 @@ be used. via a query of the name version.bind with type TXT, class CHAOS. The default is the real version number of this server. -Specifying version none; +Specifying version none disables processing of the queries. @@ -2865,10 +2892,10 @@ disables processing of the queries. The hostname the server should report via a query of the name hostname.bind with type TXT, class CHAOS. -This defaults to the hostname of the machine hosting the nameserver as +This defaults to the hostname of the machine hosting the name server as found by gethostname(). The primary purpose of such queries is to identify which of a group of anycast servers is actually -answering your queries. Specifying hostname none; +answering your queries. Specifying hostname none disables processing of the queries. @@ -2922,14 +2949,13 @@ If not specified, the default is named_dump.db. 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 /var/run/named.pid. The pid-file is used by programs that want to send signals to the running -nameserver. Specifying pid-file none; disables the +name server. Specifying pid-file none disables the use of a PID file — no file will be written and any existing one will be removed. Note that none is a keyword, not a file name, and therefore is not enclosed in @@ -2951,11 +2977,7 @@ receiving and sending DNS protocol traffic. The default is 53. This option is mainly intended for server testing; a server using a port other than 53 will not be able to communicate with the global DNS. -The port option should be placed at -the beginning of the options block, before -any other options that take port numbers or IP addresses, -to ensure that the port value takes effect for all addresses -used by the server. + random-device @@ -3016,8 +3038,8 @@ NOTIFY requests.Finer control can be achieved by using notify which only sends NOTIFY messages, notify-passive which sends NOTIFY messages and suppresses the normal refresh queries, refresh -which suppresses normal refresh processing and send refresh queries -when the heartbeat-interval expires and +which suppresses normal refresh processing and sends refresh queries +when the heartbeat-interval expires, and passive which just disables normal refresh processing. @@ -3077,8 +3099,8 @@ processing. fake-iquery -In BIND 8, this option was used to -enable simulating the obsolete DNS query type +In BIND 8, this option +enabled simulating the obsolete DNS query type IQUERY. BIND 9 never does IQUERY simulation. @@ -3102,7 +3124,7 @@ and rfc2308-type1 no instead. host-statistics In BIND 8, this enables keeping of -statistics for every host that the nameserver interacts with. +statistics for every host that the name server interacts with. Not implemented in BIND 9. @@ -3124,7 +3146,7 @@ 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 +a domain name to have multiple CNAME records in violation of the DNS standards. BIND 9.2 always strictly enforces the CNAME rules both in master files and dynamic updates. @@ -3153,7 +3175,7 @@ DNS query requests recursion, then the server will attempt to do all the work required to answer the query. If recursion is off and the server does not already know the answer, it will return a referral response. The default is yes. -Note that setting recursion no; does not prevent +Note that setting recursion no does not prevent clients from getting data from the server's cache; it only prevents new data from being cached as an effect of client queries. Caching may still occur as an effect the server's internal @@ -3174,8 +3196,10 @@ answers. The default is no. zone-statistics -If yes, the server will, by default, collect -statistical data on all zones in the server. These statistics may be accessed +If yes, the server will collect +statistical data on all zones (unless specifically turned off +on a per-zone basis by specifying zone-statistics no +in the zone statement). These statistics may be accessed using rndc stats, which will dump them to the file listed in the statistics-file. See also . @@ -3243,14 +3267,16 @@ otherwise be provided in the additional section. For example, if a query asks for an MX record for host foo.example.com, and the record found is "MX 10 mail.example.net", normally the address records (A, A6, and AAAA) for mail.example.net will be provided as well, -if known. Setting these options to no disables this behavior. +if known, even though they are not in the example.com zone. +Setting these options to no disables this behavior and makes +the server only search for additional data in the zone it answers from. 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 +recursion no will cause the server to ignore the options and log a warning message. @@ -3317,7 +3343,7 @@ difference set. 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 +name servers. 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 @@ -3357,7 +3383,8 @@ details on how to specify IP address lists. allow-notify Specifies which hosts are allowed to -notify slaves of a zone change in addition to the zone masters. +notify this server, a slave, of zone changes in addition +to the zone masters. allow-notify may also be specified in the zone statement, in which case it overrides the options allow-notify statement. It is only meaningful @@ -3367,7 +3394,7 @@ only from a zone's master. allow-query Specifies which hosts are allowed to -ask ordinary questions. allow-query may also +ask ordinary DNS 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. @@ -3438,7 +3465,7 @@ For example, listen-on port 1234 { !1.2.3.4; 1.2/16; }; -will enable the nameserver on port 53 for the IP address +will enable the name server 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. @@ -3470,7 +3497,7 @@ listen-on-v6 port 1234 { any; }; the server will not listen on any IPv6 address. Query Address If the server doesn't know the answer to a question, it will -query other nameservers. query-source specifies +query other name servers. 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, @@ -3534,7 +3561,7 @@ hour). 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 bandwith used, BIND 9 limits the rate at which queries are +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. @@ -3589,10 +3616,10 @@ 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. +that can be concurrently transferring from a given remote name server. 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 +the load on the remote name server. transfers-per-ns may be overridden on a per-server basis by using the transfers phrase of the server statement. @@ -3708,13 +3735,24 @@ server rather than the operating system. max-ixfr-log-size This option is obsolete; it is accepted -and ignored for BIND 8 compatibility. +and ignored for BIND 8 compatibility. The option +max-journal-size performs a similar +function in BIND 8. + + + +max-journal-size +Sets a maximum size for each journal file +(). When the journal file approches +the specified size, some of the oldest transactions in the journal +will be automatically removed. The default is +unlimited. recursive-clients The maximum number of simultaneous recursive lookups the server will perform on behalf of clients. The default is -1000. Because each recursing clients uses a fair +1000. Because each recursing client uses a fair bit of memory, on the order of 20 kilobytes, the value of the recursive-clients option may have to be decreased on hosts with limited memory. @@ -3764,14 +3802,15 @@ to 1 day (1440 minutes). If set to 0, no zone maintenance for these zones will o 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. +the configuration file is loaded. After the scan, the server will +begin listening for queries on any newly discovered +interfaces (provided they are allowed by the +listen-on configuration), and will +stop listening on interfaces that have gone away. statistics-interval -Nameserver statistics will be logged +Name server 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 BIND9. @@ -3783,8 +3822,8 @@ every statistics-interval minutes. The default is 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 +All other things being equal, when the server chooses a name server +to query from a list of name servers, 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. @@ -3827,7 +3866,7 @@ 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. +configuring the name servers, not all the clients. The sortlist statement (see below) takes an address_match_list and interprets it even @@ -3966,7 +4005,7 @@ PTR records. This feature is disabled by default and can be enabled on a per-client basis by adding a -allow-v6-synthesis { address_match_list }; +allow-v6-synthesis { address_match_list } clause to the options or view statement. When it is enabled, recursive AAAA queries cause the server to first try an A6 lookup and if that @@ -4017,7 +4056,7 @@ answers. The default is one week (7 days). is required for a request for the root servers to be accepted. Default is 2. -Not yet implemented in BIND9. +Not implemented in BIND9. sig-validity-interval @@ -4042,8 +4081,8 @@ are set by the master, giving slave server administrators little control over their contents. These options allow the administrator to set a minimum and maximum -refresh and retry time either per-zone, per-view, or per-server. -These options are valid for master, slave and stub zones, +refresh and retry time either per-zone, per-view, or globally. +These options are valid for master, slave and stub zones, and clamp the SOA refresh and retry times to the specified values. @@ -4145,7 +4184,7 @@ to be incremented, and may additionally cause the <command>server</command> Statement Definition and Usage The server statement defines characteristics -to be associated with a remote nameserver. +to be associated with a remote name server. The server statement can occur at the top level of the @@ -4166,7 +4205,7 @@ 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 +to the remote server will be non-incremental. If not set, the value of the provide-ixfr option in the view or global options block is used as a default. @@ -4203,11 +4242,11 @@ 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 +The keys clause identifies a +key_id defined by the key statement, +to be used for transaction security (TSIG, ) +when talking to the remote server. +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. @@ -4230,7 +4269,7 @@ and Usage The trusted-keys statement defines DNSSEC security roots. DNSSEC is described in . 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. +because it is the DNS root zone or because 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. @@ -4267,7 +4306,7 @@ the address_match_list of the view's default to matching all addresses. A view can also be specified as match-recursive-only, which means that only recursive requests from matching clients will match that view. -The order of the view statements is significant — +The order of the view statements is significant — a client request will be resolved in the context of the first view that it matches. @@ -4300,23 +4339,29 @@ are present, all zone statements must occur inside Here is an example of a typical split DNS setup implemented using view statements. view "internal" { - // This should match our internal networks. + // This should match our internal networks. match-clients { 10.0.0.0/8; }; - // Provide recursive service to internal clients only. + + // Provide recursive service to internal clients only. recursion yes; - // Provide a complete view of the example.com zone - // including addresses of internal hosts. + + // 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 all clients not matched by the previous view. match-clients { any; }; - // Refuse recursive service to external clients. + + // Refuse recursive service to external clients. recursion no; - // Provide a restricted view of the example.com zone - // containing only publicly accessible hosts. + + // Provide a restricted view of the example.com zone + // containing only publicly accessible hosts. zone "example.com" { type master; file "example-external.db"; @@ -4400,7 +4445,8 @@ 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.) +behave very slowly if you put 100 000 files into +a single directory.) stub @@ -4442,7 +4488,7 @@ of type forward can contain a forward and/ 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 +forwarding will be done for the domain, canceling 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 @@ -4452,10 +4498,10 @@ servers as set globally) you need to respecify the global forwarders. hint -The initial set of root nameservers is +The initial set of root name servers 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 +the root hints to find a root name server and get the most recent +list of root name servers. 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. @@ -4498,7 +4544,10 @@ in . allow-update Specifies which hosts are allowed to submit Dynamic DNS updates for master zones. The default is to deny -updates from all hosts. +updates from all hosts. Note that allowing updates based +on the requestor's IP address is insecure; see + for details. + update-policy @@ -4515,7 +4564,7 @@ in . 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 +for this zone is made up of all the listed name servers (other than the primary master) for the zone plus any IP addresses specified with also-notify. A port may be specified with each also-notify address to send the notify @@ -4528,7 +4577,7 @@ The default is the empty list. This option was used in BIND 8 to restrict the character set of domain names in master files and/or DNS responses received from the -netowrk. BIND 9 does not restrict the character set of domain names +network. BIND 9 does not restrict the character set of domain names and does not implement the check-names option. @@ -4607,7 +4656,7 @@ Ignored in BIND 9. 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. +on load and ignores the option. zone-statistics @@ -4745,7 +4794,7 @@ and implemented in the DNS. These are also included. 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 + need not be preserved by name servers, 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 NS -the authoritative nameserver for the +the authoritative name server for the domain. @@ -4966,7 +5015,7 @@ owner domain. The owner name is often implicit, rather than forming an integral -part of the RR. For example, many nameservers internally form tree +part of the RR. For example, many name servers 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 @@ -4988,7 +5037,7 @@ used as "pointers" to other data in the DNS. 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 +stored in a name server 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 @@ -5329,7 +5378,7 @@ you can set up and nickname for future use in allow-notify, 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 +your name server, 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 @@ -5367,10 +5416,10 @@ UNIX servers) On UNIX servers, it is possible to run BIND in a chrooted environment (chroot()) by specifying the "" option. This can help improve system security by placing BIND in -a "sandbox," which will limit the damage done if a server is compromised. +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 ( user ). -We suggest running as a nonprivileged user when using the chroot feature. +ability to run the daemon as an unprivileged user ( user ). +We suggest running as an unprivileged 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: @@ -5408,8 +5457,8 @@ 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. Note that if the named daemon is running as a -nonprivileged user, it will not be able to bind to new restricted ports if the +to write. Note that if the named daemon is running as an +unprivileged user, it will not be able to bind to new restricted ports if the server is reloaded. @@ -5519,13 +5568,13 @@ all. 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 + "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 + 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