| Previous | Contents | Index |
The server provides some helpful diagnostic information through a number of built-in zones under the pseudo-top-level-domain bind in the CHAOS class. These zones are part of a built-in view (see Section 6.2.21) of class CHAOS which is separate from the default view of class IN; therefore, any global server options such as allow-query do not apply the these zones. If you feel the need to disable these zones, use the options below, or hide the built-in CHAOS view by defining an explicit view of class CHAOS that matches all clients.
| Options | Description |
|---|---|
| version | The version the server should report 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 disables processing of the queries. |
| hostname | 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 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; disables processing of the queries. |
| server-id | The ID of the server should report via a query of the name ID.SERVER with type TXT, class CHAOS. The primary purpose of such queries is to identify which of a group of anycast servers is actually answering your queries. Specifying server-id none; disables processing of the queries. Specifying server-id hostname; will cause BIND to use the hostname as found by gethostname() . The default server-id is none. |
The statistics file generated by BIND 9 is similar, but not identical, to that generated by BIND 8.
The statistics dump begins with the following line:
+++ Statistics Dump +++ (973798949) |
The number in parentheses is a standard UNIX time stamp, measured as seconds since January 1, 1970. Following that line are a series of lines containing a counter type, the value of the counter, a zone name (optional), and a view name (optional). The lines without view and zone listed are global statistics for the entire server. Lines with a zone and view name apply to the given view and zone (the view name is omitted for the default view). The statistics dump ends with the following line:
--- Statistics Dump --- (973798949) |
The time stamp is identical to the one in the beginning line.
Table 6-18 describes the statistics counters that are maintained.
| Counter | Description |
|---|---|
| success | The number of successful queries made to the server or zone. A successful query is defined as query which returns a NOERROR response with at least one answer RR. |
| referral | The number of queries that resulted in referral responses. |
| nxrrset | The number of queries that resulted in NOERROR responses with no data. |
| nxdomain | The number of queries that resulted in NXDOMAIN responses. |
| recursion | The number of queries that caused the server to perform recursion in order to find the final answer. |
| failure | The number of queries that resulted in a failure response other than those described in the preceding counters. |
Each query received by the server will cause exactly one of success,
referral, nxrrset, nxdomain, or failure to be incremented, and may
additionally cause the recursion counter to be incremented.
6.5.3.8 The SERVER Statement
The server statement defines characteristics to be associated with a remote name server. The server statement has the following syntax:
server ip_addr {
[ bogus yes_or_no ; ]
[ provide-ixfr yes_or_no ; ]
[ request-ixfr yes_or_no ; ]
[ edns yes_or_no ; ]
[ transfers number ; ]
[ transfer-format ( one-answer | many-answers ) ; ]]
[ keys { string ; [ string ; [...]] } ; ]
[ transfer-source (ip4_addr | *) [port ip_port] ; ]
[ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
};
|
The server statement can occur at the top level of the configuration file or inside a view statement. If a view statement contains one or more server statements, only those apply to the view, and any top-level ones are ignored. If a view contains no server statements, any top-level server statements are used as defaults.
Table 6-19 describes the clauses in the server statement.
| Clause | Description |
|---|---|
| bogus | If you discover that a remote server is giving out bad data, marking it as bogus prevents further queries to it. The default value of bogus is NO. |
| provide-ixfr | Determines whether the local server, acting as master, responds with an incremental zone transfer when the given remote server, a slave, requests it. If this option is set to YES, incremental transfer is provided whenever possible. If set to NO, all transfers to the remote server are nonincremental. If not set, the value of the provide-ixfr option in the global options statement is used as a default. |
| request-ixfr |
Determines whether the local server, acting as a slave, requests
incremental zone transfers from the given remote server, a master. If
this option is not set, the value of the
request-ixfr
option in the global
options
statement is used as a default.
IXFR requests to servers that do not support IXFR automatically falls back to AXFR. Therefore, you do not need to list manually which servers support IXFR and which ones do not; the global default of YES should always work. The purpose of the provide-ixfr and request-ixfr clauses is to make it possible to disable the use of IXFR, even when both master and slave claim to support it; for example, if one of the servers crashes or corrupts data when IXFR is used. See Section 6.5.6 for more information. |
| edns | Determines whether the local server attempts to use EDNS when communicating with the remote server. The default is YES. |
| transfer-format |
Specifies the zone transfer method:
The many-answers mode is more efficient, but it is understood only by BIND Version 9, BIND Version 8, and later versions of BIND Version 4. If transfer-format is not specified, the transfer format specified by the options statement is used. |
| transfers | Limits the number of concurrent inbound zone transfers from the specified server. If no transfers clause is specified, the limit is set according to the transfers-per-ns option, as described in Table 6-13. |
| keys |
Specifies 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 is 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.
Use only one key for each server. |
| transfer-source | Specifies the IPv4 source address to be used for zone transfer with the remote server. For an IPv4 remote server, only transfer-source can be specified. |
| transfer-source-v6 | Specifies the IPv6 source address to be used for zone transfer with the remote server. For an IPv6 remote server, only transfer-source-v6 can be specified. |
The trusted-keys statement defines DNSSEC security roots. (DNSSEC is described in Section 6.2.6.)
A security root is defined when the public key for a nonauthoritative zone is known but cannot be securely obtained through DNS, either 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.
The trusted-keys statement can contain multiple key entries. The trusted-keys statement has the following syntax:
trusted-keys {
string number number number string ;
[ string number number number string ; [...]]
};
|
Each statement contains the key's domain name, flags, protocol, algorithm, and base-64 representation of the key data.
The base-64 representation of the key data must be enclosed in
quotation marks.
6.5.3.10 The VIEW Statement
The view statement allows a name server to answer a DNS query differently, depending on who is asking. It is particularly useful for implementing split DNS setups without having to run multiple servers.
The view statement has the following syntax:
view view_name [class] {
match-clients { address_match_list } ;
match-destinations { address_match_list } ;
match-recursive-only yes_or_no ;
[ view_option; ...]
[ zone_statement; ...]
};
|
The parameters to the view statement are:
All non-IN views must contain a hint zone. Only the IN class has compiled-in default hints. |
Table 6-20 describes the clauses you can include in the view statement.
| Clause | Description |
|---|---|
|
match-clients
match-destinations |
Each view statement defines a view of the DNS name space that is seen by a subset of clients. A client matches a view if its source IP address matches the address match list of the view's match-clients clause and its destination IP address matches the address match list of the view's match-destinations clause. If they are not specified, both match-clients and match-destinations default to matching all addresses. In addition to checking IP addresses match-clients and match-destinations can also take keys which provide an mechanism for the client to select the view. |
| match-recursive-only | Only recursive requests from matching clients match that view. |
| view-options | Many of the options given in the options statement can also be used in a view statement, and then apply only when resolving queries with that view. When no view statement value is given, the value in the options statement is used as the default. |
| zone-statement | Specifies the zone information for this view. See Section 6.5.3.11 for more information. |
The order of the view statements is significant. A client request is resolved in the context of the first view that it matches. Zones defined within a view statement are accessible only to clients that match the view.
By defining a zone of the same name in multiple views, different zone data can be given to different clients; for example, internal and external clients in a split DNS setup. Also, zone statement options can have default values specified in the view statement; these view-specific defaults take precedence over those in the options statement.
If there are no view statements in the configuration file, a default view that matches any client is automatically created in class IN. Any zone statements specified on the top level of the configuration file are considered to be part of this default view, and the options statement will apply to the default view. If any explicit view statements are present, all zone statements must occur inside view statements.
If any explicit view statements are present, all zone statements must occur inside view statements. |
The following example shows a typical split DNS setup implemented using view statements:
view "internal" {
// This should match our internal networks.
match-clients { 10.0.0.0/8; };
// Provide recursive service to internal clients only.
recursion yes;
// Provide a complete view of the example.com zone
// including addresses of internal hosts.
zone "example.com" {
type master;
file "example-internal.db";
};
};
view "external" {
match-clients { any; };
// Refuse recursive service to external clients.
recursion no;
// Provide a restricted view of the example.com zone
// containing only publicly accessible hosts.
zone "example.com" {
type master;
file "example-external.db";
};
};
|
The zone statement specifies options for a specific zone. Note that if view statements are included in the configuration file, the zone statements must be included in view statements.
The zone statement has the following syntax:
zone zone_name [class] [{
type ( master | slave | hint | stub | forward | delegation-only) ;
[ allow-notify { address_match_list } ; ]
[ allow-query { address_match_list } ; ]
[ allow-transfer { address_match_list } ; ]
[ allow-update { address_match_list } ; ]
[ update-policy { update_policy_rule [...] } ; ]
[ allow-update-forwarding { address_match_list } ; ]
[ also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ]
};
]
[ check-names (warn|fail|ignore) ; ]
[ dialup dialup_option ; ]
[ delegation-only yes_or_no ; ]
[ file string ; ]
[ forward (only|first) ; ]
[ forwarders { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ]
}; ]
[ ixfr-base string ; ]
[ ixfr-tmp-file string ; ]
[ maintain-ixfr-base yes_or_no ; ]
[ masters [port ip_port] { ( masters_list | ip_addr [port ip_port] [key
key] ) ; [...] } ;
[ max-transfer-idle-in number ; ]
[ max-transfer-idle-out number ; ]
[ max-transfer-time-in number ; ]
[ max-transfer-time-out number ; ]
[ notify yes_or_no | explicit ; ]
[ pubkey number number number string ; ]
[ transfer-source (ip4_addr | *) [port ip_port] ; ]
[ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]
[ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ use-alt-transfer-source yes_or_no; ]
[ notify-source (ip4_addr | *) [port ip_port] ; ]
[ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]
[ zone-statistics yes_or_no ; ]
[ sig-validity-interval number ; ]
[ database string ; ]
[ min-refresh-time number ; ]
[ max-refresh-time number ; ]
[ min-retry-time number ; ]
[ max-retry-time number ; ]
[ multi-master yes_or_no ; ]
[ key-directory path_name; ]
}];
|
Table 6-21 describes the types of zones that you can specify in the type clause.
| Type | Description |
|---|---|
| master | The server that has a master copy of the data for the zone and that can provide authoritative answers for it. |
| slave | A replica of a master zone. The masters list specifies one or more IP addresses of master servers that the slave contacts to update its copy of the zone. Masters list elements can also be names of other masters lists. By default, transfers are made from port 53 on the servers; this can be changed for all servers by specifying a port number before the list of IP addresses, or on a per-server basis after the IP address. Authentication to the master can also be done with per-server TSIG keys. If a file is specified, then the replica will be written to this file whenever the zone is changed, and reloaded from this file on a server restart. Use of a file is recommended, since it often speeds server start-up and eliminates a needless waste of bandwidth. |
| stub |
Similar to a slave zone, except that it replicates only the NS records
of a master zone instead of the entire zone. Stub zones are not a
standard part of the DNS; they are a feature specific to the BIND
implementation.
Stub zones can be used to eliminate the need for glue NS record in a parent zone at the expense of maintaining a stub zone entry and a set of name server addresses in TCPIP$BIND.CONF. This usage is not recommended for new configurations, and BIND Version 9 supports it only in a limited way. In BIND Version 4 and BIND Version 8, zone transfers of a parent zone included the NS records from stub children of that zone. This made it possible to configure child stubs only in the master server for the parent zone. BIND Version 9 never mixes together zone data from different zones in this way. Therefore, if a BIND Version 9 master serving a parent zone has child stub zones, all the slave servers for the parent zone also need to have the same child stub zones. Stub zones can also be used as a way of forcing the resolution of a given domain to use a particular set of authoritative servers. For example, the caching name servers on a private network using RFC1981 addressing may be configured with stub zones for 10.in-addr.arpa to use a set of internal name servers as the authoritative servers for that domain. |
| forward |
A forward zone allows you to configure forwarding on a per-domain
basis. A
zone
statement of type
forward
can contain
forward
and
forwarders
statements, which applies to queries within the domain specified by the
zone name. If no
forwarders
statement is present or if an empty list for forwarders is specified,
then forwarding is not done for the domain, thereby canceling the
effects of any
forwarders
in the
options
statement.
If you want to use this type of zone to change the behavior of the global forward option (using the first value to specify the zone to which to forward first, or the only value to specify forwarding to this zone only), and you want to use the same servers that are set globally, you need to respecify the global forwarders. |
| hint | 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 name server and to get the most recent list of root name servers. If no hint zone is specified for class IN, the server uses a default set of root servers hints. Classes other than IN have no built-in defaults hints. |
| delegation-only |
Used to enforce the delegation only status of infrastructure zones
(e.g., COM, NET, ORG). Any answer that is received without a explicit
or implicit delegation in the authority section will be treated as
NXDOMAIN. This does not apply to the zone apex. This SHOULD NOT be
applied to leaf zones.
delegation-only has no effect on answers received from forwarders. |
| Previous | Next | Contents | Index |