acl Statement
+acl name {
+ address_match_list
+};
+
+
+The acl statement creates a named address match list.
+It gets its name from a primary use of address match lists: Access
+Control Lists (ACLs).
Note that an address match list's name must be defined with
+acl before it can be used elsewhere; no forward
+references are allowed.
any
+none
+localhost
+localnets
+[ BIND Config. File +| BIND Home +| ISC ]
+address_match_list = 1*address_match_element + +address_match_element = [ "!" ] (address_match_list / ip_address / ip_prefix / acl_name / "key" key_id) ";" ++ +
Address match lists are primarily used to determine access control for
+various server operations. They are also used to define priorities
+for querying other nameservers and to set the addresses on which
+named will listen for queries.
+The elements which constitute an address match list can be any
+of the following:
key statement, or
+
+acl statment, orElements can be negated with a leading exclamation mark ("!"), and
+the match list names "any", "none", "localhost" and "localnets" are
+predefined. More information on those names can be found in the
+description of the acl statement.
+
+
The addition of the key
+clause made the name of this syntactic element something of a
+misnomer, since security keys can be used to validate access without
+regard to a host or network address. Nonetheless, the term "address
+match list" is still used throughout the documentation.
When a given IP address or prefix is compared to an address match
+list, the list is traversed in order until an element matches. The
+interpretation of a match depends on whether the list is being used
+for access control, defining listen-on ports, or as a
+topology, and whether the element was negated.
When used as an access control list, a non-negated match allows
+access and a negated match denies access. If there is no match,
+access is denied. The clauses allow-query,
+allow-transfer, allow-update and
+blackhole all use address match lists like this.
+Similarly, the listen-on
+option will cause the server to not accept queries on any of the
+machine's addresses which do not match the list.
+
+
When used with the topology clause, a non-negated
+match returns a distance based on its position on the list (the closer
+the match is to the start of the list, the shorter the distance is
+between it and the server). A negated match will be assigned the
+maximum distance from the server. If there is no match, the address
+will get a distance which is further than any non-negated list
+element, and closer than any negated element.
Because of the first-match aspect of the algorithm, an element that
+defines a subset of another element in the list should come before the
+broader element, regardless of whether either is negated. For
+example, in 1.2.3/24; ! 1.2.3.13; the 1.2.3.13
+element is completely useless, because the algorithm will match
+any lookup for 1.2.3.13 to the 1.2.3/24 element. Using
+! 1.2.3.13; 1.2.3/24 fixes that problem by
+having 1.2.3.13 blocked by the negation but all other 1.2.3.* hosts
+fall through.
+
+
[ BIND Config. File +| BIND Home +| ISC ]
+/* 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 ++ +
Comments may appear anywhere that whitespace may appear in a BIND +configuration file.
+ +C-style comments start with the two characters /*
+(slash, star) and end with */ (star, slash). Because
+they are completely delimited with these characters, they can be used
+to comment only a portion of a line or to span multiple lines.
C-style comments cannot be nested. For example, the following is
+not valid because the entire comment ends with the first
+*/:
+
+
+/* This is the start of a comment. + This is still part of the comment. +/* This is an incorrect attempt at nesting a comment. */ + This is no longer in any comment. */ ++ + +
C++-style comments start with the two characters //
+(slash, slash) and continue to the end of the physical line. They
+cannot be continued across multiple physical lines; to have one
+logical comment span multiple lines, each line must use the
+// pair. For example:
+
+
+// This is the start of a comment. The next line +// is a new comment, even though it is logically +// part of the previous comment. ++ +
Shell-style (or perl-style, if you prefer) comments start with the
+character # (hash or pound or number or octothorpe or
+whatever) and continue to the end of the physical line, like C++
+comments.
+# 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,
+so whatever follows it will be interpreted as the start of the next
+statement.
[ BIND Config. File +| BIND Home +| ISC ]
BIND 8 is much more configurable than previous release of BIND. +There are entirely new areas of configuration, such as access control lists +and categorized logging. Many options that previously applied to all zones +can now be used selectively. These features, plus a consideration of future +configuration needs led to the creation of a new configuration file format. + +
A BIND 8 configuration consists of statements and comments. +Statements end with a semicolon. Many statements contain a block of +substatements, which are also terminated with a semicolon.
+ +The following statements are supported: +
acl
+include
+key
+logging
+options
+controls
+server
+trusted-keys
+zone
+The logging and options statements may only
+occur once per configuration.
+
+
BIND 4.9.x configuration files can be converted to the new format
+by using src/bin/named/named-bootconf.pl, a perl script that
+is part of the BIND 8.1 source kit.
+
+
controls Statement
+controls {
+ [ inet ip_addr
+ port ip_port
+ allow { address_match_list; }; ]
+ [ unix path_name
+ perm number
+ owner number
+ group number; ]
+};
+
+
+The controlsndc utility to send commands
+to and retrieve non-DNS results from a name server.
A unix control channel is a FIFO in the file system,
+and access to it is
+controlled by normal file system permissions.
+It is created by named with the specified file mode bits (see
+the chmod(1) manual page), user and group owner.
+Note that, unlike chmod, the mode bits specified for
+perm will normally have a leading 0 so the number
+is interpreted as octal. Also note that the user and group
+ownership specified as owner and group
+must be given as numbers, not names.
+It is recommended that the
+permissions be restricted to administrative personnel only, or else any
+user on the system might be able to manage the local name server.
An inet control channel is a TCP/IP socket accessible
+to the Internet, created at the specified ip_port on the
+specified ip_addr.
+Modern telnet clients are capable of speaking directly to these
+sockets, and the control protocol is ARPAnet-style text. It is recommended
+that 127.0.0.1 be the only ip_addr used, and this only if you
+trust all non-privileged users on the local host to manage your name
+server.
Described below are elements used throughout the BIND configuration +file documentation. Elements which are only associated with one +statement are described only in the section describing that statement. + +
123 or 45.67 or
+89.123.45.67.
+
+"my.test.domain".
+
+"zones/master/my.test.domain".
+
+127/8 is
+the network 127.0.0.0 with netmask 255.0.0.0.
+1.2.3.0/24 is network 1.2.3.0 with netmask
+255.255.255.0.
+
+unlimited, or the word
+default.
+
+The maximum value of size_spec is that of unsigned long
+integers on the machine. unlimited requests unlimited use, or
+the maximum available amount. default uses the limit that
+was in force when the server was started.
A number can optionally be followed by a scaling factor:
+K or k for kilobytes, M or
+m for megabytes, and G or g for
+gigabytes, which scale by 1024, 1024*1024, and 1024*1024*1024
+respectively.
+
+
Integer storage overflow is currently silently ignored during
+conversion of scaled values, resulting in values less than intended,
+possibly even negative. Using unlimited is the best way
+to safely set a really large number.
yes or no. The words
+true and false are also accepted, as are the
+numbers 1 and 0.
+
+[ BIND Config. File +| BIND Home +| ISC ]
+
+/*
+ * A simple BIND 8 configuration
+ */
+
+logging {
+ category lame-servers { null; };
+ category cname { null; };
+};
+
+options {
+ directory "/var/named";
+};
+
+controls {
+ inet * port 52 allow { localnets; }; // a BAD idea
+ unix "/var/run/ndc" perm 0600 owner 0 group 0; // the default
+};
+
+zone "isc.org" in {
+ type master;
+ file "master/isc.org";
+};
+
+zone "vix.com" in {
+ type slave;
+ file "slave/vix.com";
+ masters { 10.0.0.53; };
+};
+
+zone "." in {
+ type hint;
+ file "named.cache";
+};
+
+zone "0.0.127.in-addr.arpa" in {
+ type master;
+ notify no;
+ file "master/127.0.0";
+};
+
+
+include Statement+include path_name; ++ +
The include statement inserts the specified file at
+the point that the include statement is encountered. It
+cannot be used within another statement, though, so a line such as
+
+acl internal_hosts { include "internal_hosts.acl"; };
+
+is not allowed.
+
+Use include to break the configuration up into
+easily-managed chunks. For example:
+
+
+include "/etc/security/keys.bind"; +include "/etc/acls.bind"; ++ +
could be used at the top of a BIND configuration file in order to +include any ACL or key information.
+ +Be careful not to type
+"#include", like you would in a C
+program, because "#" is used to start a
+comment.
[ BIND Config. File +| BIND Home +| ISC ]
key Statement
+key key_id {
+ algorithm algorithm_id;
+ secret secret_string;
+};
+
+
+The key statement defines a key ID which can be used
+in a server statement to
+associate an authentication method with a particular name server.
+
+
A key ID must be created with the key
+statement before it can be used in a server
+definition or an address match list.
The algorithm_id is a string that specifies a +security/authentication algorithm. +secret_string is the secret to be used by the algorithm, +and is treated as a base-64 encoded string. + +
The key statement is intended for use in transaction
+security. Unless included in a server
+statement, it is not used to sign any requests. It is used to verify
+requests matching the key_id and algorithm_id,
+and sign replies to those requests.
+
[ BIND Config. File +| BIND Home +| ISC ]
logging Statement
+logging {
+ [ channel channel_name {
+ ( file path_name
+ [ versions ( number | unlimited ) ]
+ [ size size_spec ]
+ | syslog ( kern | user | mail | daemon | auth | syslog | lpr |
+ news | uucp | cron | authpriv | ftp |
+ local0 | local1 | local2 | local3 |
+ local4 | local5 | local6 | local7 )
+ | null );
+
+ [ severity ( critical | error | warning | notice |
+ info | debug [ level ] | dynamic ); ]
+ [ print-category yes_or_no; ]
+ [ print-severity yes_or_no; ]
+ [ print-time yes_or_no; ]
+ }; ]
+
+ [ category category_name {
+ channel_name; [ channel_name; ... ]
+ }; ]
+ ...
+};
+
+
+The first statement in a channel definition must be one of
+file, syslog or null
+
+
The logging statement configures a wide variety of
+logging options for the nameserver. Its channel phrase
+associates output methods, format options and severity levels with
+a name that can then be used with the category phrase to
+select how various classes of messages are logged.
Only one logging statement is used to define as many
+channels and categories as are wanted. If there are multiple logging
+statements in a configuration, the first defined determines the logging,
+and warnings are issued for the others. If there is no logging statement,
+the logging configuration will be:
+ logging {
+ category default { default_syslog; default_debug; };
+ category panic { default_syslog; default_stderr; };
+ category packet { default_debug; };
+ category eventlib { default_debug; };
+ };
+
+
+The logging configuration is established as soon as the
+logging statement is parsed. If you want to redirect
+messages about processing of the entire configuration file, the
+loggingstatement must appear first. Even if you do not
+redirect configuration file parsing messages, we recommend
+always putting the logging statement first so that this
+rule need not be consciously recalled if you ever do need want the
+parser's messages relocated.
+
+channel phraseAll log output goes to one or more "channels"; you can make as many +of them as you want.
+ +Every channel definition must include a clause that says whether
+messages selected for the channel go to a file, to a particular syslog
+facility, or are discarded. It can optionally also limit the message
+severity level that will be accepted by the channel (default is
+"info"), and whether to include a named-generated time
+stamp, the category name and/or severity level (default is not to
+include any).
The word null as the destination option for the
+channel will cause all messages sent to it to be discarded; other
+options for the channel are meaningless.
The file clause can include limitations both on how
+large the file is allowed to become, and how many versions of the file
+will be saved each time the file is opened.
+
+
The size option for files is simply a hard ceiling on
+log growth. If the file ever exceeds the size, then
+named will just not write anything more to it until the
+file is reopened; exceeding the size does not automatically trigger a
+reopen. The default behavior is to not limit the size of the file.
If you use the version logfile option, then
+named will retain that many backup versions of the file
+by renaming them when opening. For example, if you choose to keep 3
+old versions of the file "lamers.log" then just before it is opened
+lamers.log.1 is renamed to lames.log.2, lamers.log.0 is renamed to
+lamers.log.1, and lamers.log is renamed to lamers.log.0. No rolled
+versions are kept by default; any existing log file is simply
+appended. The unlimited keyword is synonymous with
+99 in current BIND releases.
The argument for the syslog clause is a syslog
+facility as described in the syslog manual page. How
+syslogd will handle messages sent to this facility is
+described in the syslog.conf manual page. If you have a
+system which uses a very old version of syslog that only
+uses two arguments to the openlog() function, then this
+clause is silently ignored.
The severity clause works like syslog's
+"priorities", except that they can also be used if you are writing
+straight to a file rather than using syslog. Messages
+which are not at least of the severity level given will not be
+selected for the channel; messages of higher severity levels will be
+accepted.
If you are using syslog, then the
+syslog.conf priorities will also determine what
+eventually passes through. For example, defining a channel facility
+and severity as daemon and debug but only
+logging daemon.warning via syslog.conf will
+cause messages of severity info and notice
+to be dropped. If the situation were reversed, with
+named writing messages of only warning or
+higher, then syslogd would print all messages it received
+from the channel.
The server can supply extensive debugging information when it is in
+debugging mode. If the server's global debug level is greater than
+zero, then debugging mode will be active. The global debug level is
+set either by starting the named server with the "-d"
+flag followed by a positive integer, or by sending the running server the
+SIGUSR1 signal (for example, by using "ndc trace"). The global debug
+level can be set to zero, and debugging mode turned off, by sending
+the server the SIGUSR2 signal ("ndc notrace"). All debugging messages
+in the server have a debug level, and higher debug levels give more
+more detailed output.
+Channels that specify a specific debug severity, e.g.
+
+
+ channel specific_debug_level {
+ file "foo";
+ severity debug 3;
+ };
+
+
+will get debugging output of level 3 or less any time the
+server is in debugging mode, regardless of the global debugging level.
+Channels with dynamic severity use the server's global
+level to determine what messages to print.
+
+
If print-time has been turned on, then the date and
+time will be logged. print-time may be specified for a
+syslog channel, but is usually pointless since syslog also prints the
+date and time. If print-category is requested,
+then the category of the message will be logged as well. Finally, if
+print-severity is on, then the severity level of the
+message will be logged. The print- options may be used
+in any combination, and will always be printed in the following order:
+time, category, severity. Here is an example where all three
+print- options are on:
+
+
+ 28-Apr-1997 15:05:32.863 default: notice: Ready to answer queries. ++ +
There are four predefined channels that are used for
+named's default logging as follows. How they are used
+used is described in the next section, The category phrase.
+
+
+ channel default_syslog {
+ syslog daemon; # send to syslog's daemon facility
+ severity info; # only send priority info and higher
+ };
+
+ channel default_debug {
+ file "named.run"; # write to named.run in the working directory
+ # Note: stderr is used instead of "named.run"
+ # if the server is started with the "-f" option.
+ severity dynamic; # log at the server's current debug level
+ };
+
+ channel default_stderr { # writes to stderr
+ file "<stderr>"; # this is illustrative only; there's currently
+ # no way of specifying an internal file
+ # descriptor in the configuration language.
+ severity info; # only send priority info and higher
+ };
+
+ channel null {
+ null; # toss anything sent to this channel
+ };
+
+
+Once a channel is defined, it cannot be redefined. Thus you cannot +alter the built-in channels directly, but you can modify the default +logging by pointing categories at channels you have defined.
+ +category phraseThere are many categories, so you can send the logs you want to see
+wherever you want, without seeing logs you don't want. If you don't specify
+a list of channels for a category, then log messages in that category will
+be sent to the default category instead. If you don't specify
+a default category, the following "default default" is used:
+
+
+ category default { default_syslog; default_debug; };
+
+
+As an example, let's say you want to log security events to a file, +but you also want keep the default logging behavior. You'd specify the +following: + +
+ channel my_security_channel {
+ file "my_security_file";
+ severity info;
+ };
+ category security { my_security_channel; default_syslog; default_debug; };
+
+
+To discard all messages in a category, specify the
+null channel:
+
+
+ category lame-servers { null; };
+ category cname { null; };
+
+
+The following +categories are available:
+ +default
+category default { default_syslog; default_debug; };
+
+config
+parser
+queries
+lame-servers
+statistics
+panic
+category panic { default_syslog; default_stderr; };
+
+update
+ncache
+xfer-in
+xfer-out
+db
+eventlib
+category eventlib
+{ default_debug; };
+
+packet
+category packet
+{ default_debug; };
+
+notify
+cname
+security
+os
+insist
+maintenance
+load
+response-checks
+[ BIND Config. File +| BIND Home +| ISC ]
+The Master File Format was initially defined in +RFC 1035 +and has subsequently been extended. +
+While the Master File Format is class independent all records in a +Master File must be of the same class. + +
$ORIGIN <domain-name> [<comment>]
+
+$ORIGIN set the domain name that will be appended to any
+unqualified records.
+When a zone is first read in there is an implict $ORIGIN
+<zone-name>.
+The current $ORIGIN is appended to the domain specified in the
+$ORIGIN argument if it is not absolute.
+
+
+$ORIGIN EXAMPLE. +$ORIGIN MYZONE +WWW CNAME MAIN-SERVER ++is equivlent to +
+WWW.MYZONE.EXAMPLE. CNAME MAIN-SERVER.MYZONE.EXAMPLE. ++ +
$INCLUDE <filename> [<origin>] [<comment>]
+
+Read and process the file filename as if it was included into the file at this
+point. If origin is specified the file is processed with $ORIGIN
+set to that value otherwise the current $ORIGIN is used.
+NOTE: The behaviour when <origin> is specified differs from that
+described in
+RFC 1035.
+
+The origin and current domain revert to the values they were prior to the
+$INCLUDE once the file has been read.
+
$TTL <default-ttl> [<comment>]
++Set the default Time To Live (TTL) for subsequent records with undefined +TTL's. Valid TTL's are of the range 0-2147483647. +
+$TTL is defined in
+RFC 2308.
+
$GENERATE <range> <lhs> <type> <rhs>
+[<comment>]
+
+$GENERATE is used to create a series of resource records
+that only differ from each other by an iterator. $GENERATE
+can be used to easily generate the sets of records required to support
+sub /24 reverse delegations described in
+RFC 2317: Classless IN-ADDR.ARPA delegation.
+
+
+$ORIGIN 0.0.192.IN-ADDR.ARPA. +$GENERATE 1-2 0 NS SERVER$.EXAMPLE. +$GENERATE 1-127 $ CNAME $.0 ++is equivalent to +
+0.0.0.192.IN-ADDR.ARPA NS SERVER1.EXAMPLE. +0.0.0.192.IN-ADDR.ARPA NS SERVER2.EXAMPLE. +1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA +2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA +... +127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA ++
{<domain>|@|<blank>}
+[<ttl>] [<class>] <type> <rdata>
+[<comment>]
++All resource records have the same basic syntax. +
domain$ORIGIN is appended.
+@$ORIGIN for the domain name for this record.
+blankttlclasstyperdataoptions Statement
+options {
+ [ version version_string; ]
+ [ directory path_name; ]
+ [ named-xfer path_name; ]
+ [ dump-file path_name; ]
+ [ memstatistics-file path_name; ]
+ [ pid-file path_name; ]
+ [ statistics-file path_name; ]
+ [ auth-nxdomain yes_or_no; ]
+ [ deallocate-on-exit yes_or_no; ]
+ [ dialup yes_or_no; ]
+ [ fake-iquery yes_or_no; ]
+ [ fetch-glue yes_or_no; ]
+ [ has-old-clients yes_or_no; ]
+ [ host-statistics yes_or_no; ]
+ [ multiple-cnames yes_or_no; ]
+ [ expert-mode yes_or_no; ]
+ [ notify yes_or_no; ]
+ [ recursion yes_or_no; ]
+ [ rfc2308-type1 yes_or_no; ]
+ [ use-id-pool yes_or_no; ]
+ [ forward ( only | first ); ]
+ [ forwarders { [ in_addr ; [ in_addr ; ... ] ] }; ]
+ [ check-names ( master | slave | response ) ( warn | fail | ignore); ]
+ [ allow-query { address_match_list }; ]
+ [ allow-transfer { address_match_list }; ]
+ [ blackhole { address_match_list }; ]
+ [ listen-on [ port ip_port ] { address_match_list }; ]
+ [ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ] ; ]
+ [ lame-ttl number; ]
+ [ max-transfer-time-in number; ]
+ [ max-ncache-ttl number; ]
+ [ transfer-format ( one-answer | many-answers ); ]
+ [ transfers-in number; ]
+ [ transfers-out number; ]
+ [ transfers-per-ns number; ]
+ [ maintain-ixfr-base yes_or_no; ]
+ [ 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 ; ... ] ] };
+};
+
+The options statement sets up global options to be used by +BIND. This statement may appear at only once in a +configuration file; if more than one occurrence is found, the +first occurrence determines the actual options used, +and a warning will be generated. If there is no options statement, +an options block with each option set to its default will be used.
+ +version
+version.bind in class chaos.
+The default is the real version number of ths server, but some server
+operators prefer the string "surely you must be joking".
+
+directory
+named-xfer
+dump-file
+SIGINT signal (ndc dumpdb). If not
+specified, the default is "named_dump.db".
+
+memstatistics-file
+deallocate-on-exit is yes. If not
+specified, the default is "named.memstats".
+
+pid-file
+statistics-file
+SIGILL signal (ndc stats). If not
+specified, the default is "named.stats".
+auth-nxdomain
+yes, then the AA bit is always set on
+NXDOMAIN responses, even if the server is not actually authoritative.
+The default is yes. Do not turn off
+auth-nxdomain unless you are sure you know what you are
+doing, as some older software won't like it.
+
+deallocate-on-exit
+yes, then when the server exits it will painstakingly
+deallocate every object it allocated, and then write a memory usage report to
+the memstatistics-file. The default is no, because
+it is faster to let the operating system clean up.
+deallocate-on-exit is handy for detecting memory leaks.
+
+dialup
+yes, then the server treats all zones as if they are
+doing zone transfers across a dial on demand dialup link, which can
+be brought up by traffic originating from this server. This has
+different effects according to zone type and concentrates the zone
+maintenance so that it all happens in a short interval, once every
+heartbeat-interval and hopefully during the one call.
+It also suppresses some of the normal zone maintainance traffic.
+The default is no. The dialup
+option may also be specified in the zone statement, in which
+case it overrides the options dialup statement.
+
+
+If the zone is a master then the server will send out
+NOTIFY request to all the slaves. This will trigger the zone up to
+date checking in the slave (providing it supports NOTIFY) allowing
+the slave to verify the zone while the call us up.
+
+
+If the zone is a slave or stub then the server
+will suppress the zone regular zone up to date queries and only perform
+the when the heartbeat-interval expires.
+
+
fake-iquery
+yes, the server will simulate the obsolete DNS query type
+IQUERY. The default is no.
+
+fetch-glue
+yes (the default), the server will fetch "glue" resource
+records it doesn't have when constructing the additional data section of
+a response. fetch-glue no can be used in conjunction with
+recursion no to prevent the server's cache from growing or
+becoming corrupted (at the cost of requiring more work from the client).
+
+has-old-clients
+yes is equivalent to setting the follow
+three options auth-nxdomain yes;, maintain-ixfr-base
+yes; and rfc2308-type1 no;.
+The use of has-old-clients with auth-nxdomain,
+maintain-ixfr-base and rfc2308-type1 is order
+dependant.
+
+host-statistics
+yes, then statistics are kept for every host that the
+the nameserver interacts with. The default is no. Note:
+turning on host-statistics can consume huge amounts of memory.
+
+maintain-ixfr-base
+yes, then a transaction log is kept for
+Incremental Zone Transfer. The default is no.
+
+multiple-cnames
+yes, then multiple CNAME resource records will be
+allowed for a domain name. The default is no. Allowing
+multiple CNAME records is against standards and is not recommended.
+Multiple CNAME support is available because previous versions of BIND
+allowed multiple CNAME records, and these records have been used for load
+balancing by a number of sites.
+
+expert-mode
+no (the default), then warnings for various minor
+problems (such as lame servers) will be issued.
+
+notify
+yes (the default), DNS NOTIFY messages are sent when a
+zone the server is authoritative for changes. The use of NOTIFY
+speeds convergence between the master and its slaves. Slave servers
+that receive a NOTIFY message and understand it will contact the
+master server for the zone and see if they need to do a zone transfer, and
+if they do, they will initiate it immediately. The notify
+option may also be specified in the zone statement, in which
+case it overrides the options notify statement.
+
+recursion
+yes, and a DNS query requests recursion, then the
+server will attempt to do all the work required to answer the query.
+If recursion is not on, the server will return a referral to the
+client if it doesn't know the answer. The default is yes.
+See also fetch-glue above.
+
+rfc2308-type1
+yes, the server will send NS records along with the SOA
+record for negative answers.
+You need to set this to no if you have an old BIND
+server using you as a forwarder that does not understand negative answers
+which contain both SOA and NS records or you have an old version of sendmail.
+The correct fix is to upgrade the broken server or sendmail.
+The default is no.
+
+use-id-pool
+yes, the server will keep track of its own outstanding
+query ID's to avoid duplication and increase randomness. This will result
+in 128KB more memory being consumed the server.
+The default is no.
+The forwarding facility can be used to create a large site-wide +cache on a few servers, reducing traffic over links to external +nameservers. It can also be used to allow queries by servers that do +not have direct access to the Internet, but wish to look up exterior +names anyway. Forwarding occurs only on those queries for which the +server is not authoritative and does not have the answer in its cache. + +
forward
+forwarders list is
+not empty. A value of first, the default, causes the
+server to query the forwarders first, and if that doesn't answer the
+question the server will then look for the answer itself. If
+only is specified, the server will only query the
+forwarders.
+
+forwarders
+Forwarding can also be configured on a per-zone basis, allowing for
+the global forwarding options to be overridden in a variety of ways.
+You can set particular zones to use different forwarders, or have
+different forward only/first behavior, or to not forward
+at all. See the zone statement
+for more information.
+
+
Future versions of BIND 8 will provide a more powerful forwarding
+system. The syntax described above will continue to be supported.
+
+Name Checking
+
+
The server can check domain names based upon their expected client contexts. +For example, a domain name used as a hostname can be checked for compliance +with the RFCs defining valid hostnames. + +
Three checking methods are available: + +
ignore
+warn
+fail
+The server can check names three areas: master zone files, slave
+zone files, and in responses to queries the server has initiated. If
+check-names response fail has been specified, and
+answering the client's question would require sending an invalid name
+to the client, the server will send a REFUSED response code to the
+client.
+
+
The defaults are: + +
+ check-names master fail; + check-names slave warn; + check-names response ignore; ++ +
check-names may also be specified in the
+zone
+statement, in which case it overrides the options check-names
+statement. When used in a zone statement, the area is not
+specified (because it can be deduced from the zone type).
+
+Access Control
+
+
Access to the server can be restricted based on the IP address of the +requesting system. See +address_match_list for details +on how to specify IP address lists. + +
allow-query
+allow-query may also be specified in the
+zone statement, in which case it overrides the
+options allow-query statement. If not specified, the default is
+to allow queries from all hosts.
+
+allow-transfer
+allow-transfer may also be specified in the
+zone statement, in which case it overrides the
+options allow-transfer statement. If not specified, the default
+is to allow transfers from all hosts.
+
+blackhole
+The interfaces and ports that the server will answer queries from may
+be specified using the listen-on option. listen-on
+takes an optional port, and an
+address_match_list. The server will
+listen on all interfaces allowed by the address match list. If a port is
+not specified, port 53 will be used.
+
+
Multiple listen-on statements are allowed. For example,
+
+
+ listen-on { 5.6.7.8; };
+ listen-on port 1234 { !1.2.3.4; 1.2/16; };
+
+
+will enable the nameserver on port 53 for the IP address 5.6.7.8, and
+on port 1234 of an address on the machine in net 1.2 that is not
+1.2.3.4.
+
+If no listen-on is specified, the server will listen on port
+53 on all interfaces.
+
+
If the server doesn't know the answer to a question, it will query
+other nameservers. query-source specifies the address
+and port used for such queries. 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 default is
+
+
+ query-source address * port *; ++ +
Note: query-source currently applies only to UDP queries;
+TCP queries always use a wildcard IP address and a random unprivileged
+port.
+
+Zone Transfers
+
+
max-transfer-time-in
+named-xfer processes) running
+longer than this many minutes will be terminated. The default is 120
+minutes (2 hours).
+
+transfer-format
+one-answer uses one DNS message per resource record
+transferred. many-answers packs as many resource records
+as possible into a message. many-answers is more
+efficient, but is only known to be understood by BIND 8.1 and patched
+versions of BIND 4.9.5. The default is one-answer.
+transfer-format may be
+overridden on a per-server basis by using the server statement.
+
+transfers-in
+transfers-in may speed up the convergence of slave zones,
+but it also may increase the load on the local system.
+
+transfers-out
+transfers-per-ns
+named-xfer
+processes) that can be concurrently transferring from a given remote
+nameserver. The default value is 2. Increasing
+transfers-per-ns may speed up the convergence of slave
+zones, but it also may increase the load on the remote nameserver.
+transfers-per-ns may be overridden on a per-server basis
+by using the transfers phrase of the server
+statement.
+The server's usage of many system resources can be limited. Some
+operating systems don't support some of the limits. On such systems,
+a warning will be issued if the unsupported limit is used. Some
+operating systems don't support limiting resources, and on these systems
+a cannot set resource limits on this system message will
+be logged.
+
+
Scaled values are allowed when specifying resource limits. For
+example, 1G can be used instead of
+1073741824 to specify a limit of one gigabyte.
+unlimited requests unlimited use, or the maximum
+available amount. default uses the limit that was in
+force when the server was started. See
+size_spec for more details.
+
+
coresize
+default.
+
+datasize
+default.
+
+files
+unlimited. Note: on some operating
+systems the server cannot set an unlimited value and cannot determine
+the maximum number of open files the kernel can support. On such
+systems, choosing unlimited will cause the server to use
+the larger of the rlim_max for RLIMIT_NOFILE
+and the value returned by sysconf(_SC_OPEN_MAX). If the
+actual kernel limit is larger than this value, use limit
+files to specify the limit explicitly.
+
+max-ixfr-log-size
+max-ixfr-log-size will be used in a future release of
+the server to limit the size of the
+transaction log kept for Incremental Zone Transfer.
+
+stacksize
+default.
+cleaning-interval
+cleaning-interval minutes. The default is 60 minutes. If set
+to 0, no periodic cleaning will occur.
+
+heartbeat-interval
+dialup yes whenever this interval expires.
+The default is 60 minutes. Reasonable values are up to 1 day (1440 minutes).
+If set to 0, no zone maintenance for these zones will occur.
+interface-interval
+interface-interval minutes. The default is 60 minutes.
+If set to 0, interface scanning will only occur when the configuration
+file is loaded. After the scan, listeners will be started on any new
+interfaces (provided they are allowed by the listen-on
+configuration). Listeners on interfaces that have gone away will be
+cleaned up.
+
+statistics-interval
+statistics-interval
+minutes. The default is 60. If set to 0, no statistics will be logged.
+All other things being equal, when the server chooses a nameserver
+to query from a list of nameservers, it prefers the one that is
+topologically closest to itself. The topology statement
+takes an address_match_list
+and interprets it in a special way. Each top-level list element is
+assigned a distance. Non-negated elements get a distance based on
+their position in the list, where the closer the match is to the start
+of the list, the shorter the distance is between it and the server. A
+negated match will be assigned the maximum distance from the server.
+If there is no match, the address will get a distance which is further
+than any non-negated list element, and closer than any negated
+element. For example,
+
+
+ topology {
+ 10/8;
+ !1.2.3/24;
+ { 1.2/16; 3/8; };
+ };
+
+
+will prefer servers on network 10 the most, followed by hosts on +network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the exception +of hosts on network 1.2.3 (netmask 255.255.255.0), which is preferred least +of all. + +
The default topology is + +
+ topology { localhost; localnets; };
+
+
++When returning multiple RRs, +the nameserver will normally return them in +Round Robin, +i.e. after each request, the first RR is put to the end of the list. +As the order of RRs is not defined, this should not cause any problems. +
++The client resolver code should re-arrange the RRs as appropriate, +i.e. using any addresses on the local net in preference to other addresses. +However, not all resolvers can do this, or are not correctly configured. +
++When a client is using a local server, the sorting can be performed in the +server, based on the client's address. +This only requires configuring the nameservers, not all the clients. +
++The sortlist statement takes an address match list and interprets it even +more specially than the topology statement does. +
++Each top level statement in the sortlist must itself be an explicit +address match list with one or two elements. The first element +(which may be an IP address, an IP prefix, an ACL name or nested +address match list) of each top level list is checked against the +source address of the query until a match is found. +
++Once the source address of the query has been matched, if the top level +statement contains only one element, the actual primitive element that +matched the source address is used to select the address in the response +to move to the beginning of the response. If the statement is a list +of two elements, then the second element is treated like the address +match list in a topology statement. Each top level element is assigned +a distance and the address in the response with the minimum distance is +moved to the beginning of the response. +
++In the following example, any queries received from any of the addresses +of the host itself will get responses preferring addresses on any of +the locally connected networks. Next most preferred are addresses on +the 192.168.1/24 network, and after that either the 192.168.2/24 or +192.168.3/24 network with no preference shown between these two networks. +Queries received from a host on the 192.168.1/24 network will prefer +other addresses on that network to the 192.168.2/24 and 192.168.3/24 +networks. Queries received from a host on the 192.168.4/24 or the +192.168.5/24 network will only prefer other addresses on their +directly connected networks. +
+sortlist {
+ { localhost; // IF the local host
+ { localnets; // THEN first fit on the
+ 192.168.1/24; // following nets
+ { 192,168.2/24; 192.168.3/24; }; }; };
+ { 192.168.1/24; // IF on class C 192.168.1
+ { 192.168.1/24; // THEN use .1, or .2 or .3
+ { 192.168.2/24; 192.168.3/24; }; }; };
+ { 192.168.2/24; // IF on class C 192.168.2
+ { 192.168.2/24; // THEN use .2, or .1 or .3
+ { 192.168.1/24; 192.168.3/24; }; }; };
+ { 192.168.3/24; // IF on class C 192.168.3
+ { 192.168.3/24; // THEN use .3, or .1 or .2
+ { 192.168.1/24; 192.168.2/24; }; }; };
+ { { 192.168.4/24; 192.168.5/24; }; // if .4 or .5, prefer that net
+ };
+};
+
+The following example will give reasonable behaviour for the local host
+and hosts on directly connected networks. It is similar to the behavior
+of the address sort in BIND 4.9.x. Responses sent to queries from the
+local host will favor any of the directly connected networks. Responses
+sent to queries from any other hosts on a directly connected network will
+prefer addresses on that same network. Responses to other queries will
+not be sorted.
+
+sortlist {
+ { localhost; localnets; };
+ { localnets; };
+};
+
+
+
+
+
+When multiple records are returned in an answer it may be useful to +configure the order the records are placed into the response. For example the +records for a zone might be configured to always be returned in the order they +are defined in the zone file. Or perhaps a random shuffle of the +records as they are returned is wanted. The rrset-order statement +permits configuration of the ordering made of the records in a multiple record +response. The default, if no ordering is defined, is a cyclic ordering (round +robin). + +
An order_spec is defined as follows: + +
+ [ class class_name ][ type type_name ][ name "FQDN" ] order ordering ++ +
If no class is specified, the default is ANY. If no
+type is specified, the default is ANY. If no
+name is specified, the default is "*".
+
+
The legal values for ordering are:
+
+
fixed
+random
+cyclic
+For example: + +
+ rrset-order {
+ class IN type A name "rc.vix.com" order random;
+ order cyclic;
+ };
+
+
+will cause any responses for type A records in class +IN that have "rc.vix.com" as a suffix, to always be returned in +random order. All other records are returned in cyclic order. + +
If multiple rrset-order statements appear, they are not
+combined--the last one applies.
+
+
If no rrset-order statement is specified, then a default one
+of:
+
+
+ rrset-order { class ANY type ANY name "*" order cyclic ; };
+
+
+is used. + +
lame-ttl
+max-ncache-ttl
+max-ncache-ttl is used to set a maximum retention time
+for these answers in the server is seconds. The default max-ncache-ttl is
+10800 seconds (3 hours). max-ncache-ttl cannot exceed the
+maximum retention time for ordinary (positive) answers (7 days) and will be
+silently truncated to 7 days if set to a value which is greater that 7 days.
+[ BIND Config. File +| BIND Home +| ISC ]
server Statement+server ip_addr { + [ bogus yes_or_no; ] + [ support-ixfr yes_or_no; ] + [ transfers number; ] + [ transfer-format ( one-answer | many-answers ); ] + [ keys { key_id [key_id ... ] }; ] +}; ++ +
The server statement defines the characteristics to be +associated with a remote name server.
+ +If you discover that a server is giving out bad data, marking it as
+bogus will prevent further queries to it. The default value of
+bogus is no.
+
+
The server supports two zone transfer methods. The first,
+one-answer, uses one DNS message per resource record
+transferred. many-answers packs as many resource records
+as possible into a message. many-answers is more
+efficient, but is only known to be understood by BIND 8.1 and patched
+versions of BIND 4.9.5. You can specify which method to use for a
+server with the transfer-format option. If
+transfer-format is not specified, the transfer-format
+specified by the options statement will be used.
+
+
The transfers will be used in a future release of the server
+to limit the number of concurrent in-bound zone transfers from the specified
+server. It is checked for syntax but is otherwise ignored.
+
+
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 statememnt must come before the server
+statement that references it. When a request is sent to the remote server,
+a request signature will be generated using the key specified here and
+appended to the message. A request originating from the remote server is not
+required to be signed by this key.
+
+
[ BIND Config. File +| BIND Home +| ISC ]
trusted-keys Statement
+trusted-keys {
+ [ domain_name number number number string; ]
+};
+
+
+
+trusted-keys
+statement is for use with DNSSEC-style security, originally specified
+in RFC 2065. DNSSEC is meant to
+provide three distinct services: key distribution, data origin
+authentication, and transaction and request authentication. A
+complete description of DNSSEC and its use is beyond the scope of this
+document, and readers interested in more information should start with
+
+RFC 2065 and then continue with the
+
+Internet Drafts.
+
+Each trusted key is associated with a domain name. Its attributes are +the non-negative integral flags, protocol, and +algorithm, as well as a base-64 encoded string representing +the key.
+ +A trusted key is added when a public key for a non-authoritative zone is +known, but cannot be securely obtained through DNS. This occurs when +a signed zone is a child of an unsigned zone. Adding the trusted +key here allows data signed by that zone to be considered secure. + +[ BIND Config. File +| BIND Home +| ISC ]
zone Statement+zone domain_name [ ( in | hs | hesiod | chaos ) ] { + type master; + file path_name; + [ check-names ( warn | fail | ignore ); ] + [ allow-update { address_match_list }; ] + [ allow-query { address_match_list }; ] + [ allow-transfer { address_match_list }; ] + [ dialup yes_or_no; ] + [ notify yes_or_no; ] + [ also-notify { ip_addr; [ ip_addr; ... ] }; + [ ixfr-base path_name; ] + [ pubkey number number number string; ] +}; + +zone domain_name [ ( in | hs | hesiod | chaos ) ] { + type slave; + [ file path_name; ] + [ ixfr-base path_name; ] + masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] }; + [ check-names ( warn | fail | ignore ); ] + [ allow-update { address_match_list }; ] + [ allow-query { address_match_list }; ] + [ allow-transfer { address_match_list }; ] + [ transfer-source ip_addr; ] + [ max-transfer-time-in number; ] + [ dialup yes_or_no; ] + [ notify yes_or_no; ] + [ also-notify { ip_addr; [ ip_addr; ... ] }; + [ pubkey number number number string; ] +}; + + +zone domain_name [ ( in | hs | hesiod | chaos ) ] { + type stub; + [ file path_name; ] + masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] }; + [ check-names ( warn | fail | ignore ); ] + [ allow-update { address_match_list }; ] + [ allow-query { address_match_list }; ] + [ allow-transfer { address_match_list }; ] + [ dialup yes_or_no; ] + [ transfer-source ip_addr; ] + [ max-transfer-time-in number; ] + [ pubkey number number number string; ] +}; + +zone domain_name [ ( in | hs | hesiod | chaos ) ] { + type forward; + [ forward ( only | first ); ] + [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ] + [ check-names ( warn | fail | ignore ); ] +}; + +zone "." [ ( in | hs | hesiod | chaos ) ] { + type hint; + file path_name; + [ check-names ( warn | fail | ignore ); ] +}; ++ +
+The type statement must come first in the body of the
+zone statement.
+
+
+
master
+slave
+slave zone is a replica of a master zone. The
+masters list specifies one or more IP addresses that the
+slave contacts to update its copy of the zone. If a port
+is specified then checks to see if the zone is current and zone transfers
+will be done to the port given. If file
+is specified, then the replica will be written to this file whenever
+the zone is changed, and reloaded from this file on a server restart.
+Use of
+file is recommended, since it often speeds server startup
+and eliminates a needless waste of bandwidth. Note that for large numbers
+(in the tens or hundreds of thousands) of zones per server, it is best to
+use a two level naming scheme for zone file names. For example, a slave
+server for the zone vix.com might place the zone contents into
+a file called "vi/vix.com" where vi/ is just the
+first two letters of the zone name. (Most operating systems behave very
+slowly if you put 100K files into a single directory.)
+
+stub
+stub zone is like a slave zone, except that it replicates
+only the NS records of a master zone instead of the entire zone.
+
+forward
+forward zone is used to
+direct all queries in it to other servers. The specification of
+options in such a zone will override any global options
+declared in the options statement.
+
+If either no forwarders statement is present in the
+zone or an empty list for forwarders is given, then no
+forwarding will be done for the zone, cancelling the effects of any
+forwarders in the options statement.
+Thus if you want to use this
+type of zone to change the behavior of the global forward
+option, and not the servers used, then you also need to respecify the
+global forwarders.
+
+
hint
+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.
+Note: previous releases of BIND used the term primary for a +master zone, secondary for a slave zone, and cache for +a hint zone.
+ +The zone's name may optionally be followed by a class. If a class
+is not specified, class in (for "internet"), is assumed.
+This is correct for the vast majority of cases.
+
+
The hesiod class is for an information service from MIT's
+Project Athena. It is used to share information about various systems
+databases, such as users, groups, printers and so on. More
+information can be found at
+MIT.
+The keyword hs is a synonym for hesiod.
Another MIT development was CHAOSnet, a LAN protocol created in the
+mid-1970s. It is still sometimes seen on LISP stations and other
+hardware in the AI community, and zone data for it can be specified
+with the
+chaos class.
check-names
+allow-query
+allow-query in the
+Access Control section.
+
+allow-update
+allow-transfer
+allow-transfer in
+the Access Control section.
+
+transfer-source
+transfer-source determines which local address will be bound to
+the TCP connection used to fetch this zone. If not set, it defaults to a
+system controlled value which will usually be the address of the interface
+``closest to'' the remote end. This address must appear in the remote end's
+allow-transfer option for this zone if one is specified.
+
+ixfr_base
+ixfr_base
+Specifies the file name used for IXFR transaction log file.
+
+max-transfer-time-in
+max-transfer-time-in in
+the Zone Transfers section.
+
+dialup
+dialup in
+the Boolean Options section.
+
+notify
+notify in
+the Boolean Options section.
+
+also-notify
+also-notify is 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
+for the zone (other than the primary master) plus any IP addresses
+specified with also-notify. also-notify is not
+meaningful for stub zones. The default is the empty list.
+
+forward
+forward is 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
+forwarders option in a zone is 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.
+
+pubkey
+[ BIND Config. File +| BIND Home +| ISC ]