| Previous | Contents | Index |
Access to the server can be restricted based on the IP address of the requesting system. Table 5-7 describes the access control options.
| Option | Description |
|---|---|
| allow-query | Specifies which hosts are allowed to ask ordinary questions. The allow-query option can also be specified in the zone statement, in which case it overrides the option allow-query statement. If not specified, the default is to allow queries from all hosts. |
| allow-transfer | Specifies which hosts are allowed to receive zone transfers from the server. The allow-transfer option can also be specified in the zone statement, in which case it overrides the option allow-transfer statement. If not specified, the default is to allow transfers from all hosts. |
Example 5-5 shows how to specify an options statement to control access to the server.
| Example 5-5 Access Control Options |
|---|
options {
allow-query { any; } ;
allow-transfer {
1.2.3/24;
5.6.7.8;
};
};
|
The interfaces and ports from which the server answers queries can be specified using the listen-on option. The listen-on option takes an optional port and an address_match_list . The server listens on all interfaces allowed by the address match list. All queries must be directed to the interface and port number specified on the listen-on statement. If a port is not specified, the server uses port 53.
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; };
|
If a
listen-on
option is not specified, the server listens on port 53 on all
interfaces.
5.3.2.7 Query Address
If the server does not know the answer to a question, it queries other name servers. The query-source option specifies the source address and source port used for such queries. If the address is an asterisk (*) or is omitted, the server uses a wildcard IP address (INADDR_ANY). If the port is an asterisk (*) or is omitted, the server uses a random unprivileged port. The default query-source statement is as follows:
query-source address * port *;
|
The
query-source
option currently applies only to UDP queries; TCP queries always use a
wildcard IP address and a random unprivileged port.
5.3.2.8 Zone Transfers
Table 5-8 describes the zone transfer options.
| Option | Description |
|---|---|
| max-transfer-time-in | Inbound zone transfers (BIND_SERVER_XFER processes) running longer than this many minutes are terminated. The default is 120 minutes (2 hours). |
| transfer-format | The server supports two zone transfer methods. The one-answer method uses one DNS message per resource record transferred. The many-answers method packs as many resource records as possible into a message. The many-answers method is more efficient, but it is understood only by BIND 8.1 and patched versions of BIND 4.9.5. The default is one-answer . The transfer-format option can be overridden on a per-server basis by using the server statement. |
| transfers-in | The maximum number of inbound zone transfers that can be running concurrently. The default value is 10. Increasing transfers-in can speed the convergence of slave zones, but can also increase the load on the local system. |
| transfers-per-ns | The maximum number of inbound zone transfers (BIND_SERVER_XFER processes) that can be concurrently transferring from a given remote name server. The default value is 2. Increasing transfers-per-ns can speed the convergence of slave zones, but it can also increase the load on the remote name server. transfers-per-ns can be overridden on a per-server basis by using the transfers phrase of the server statement. |
Example 5-6 shows how to specify an options statement to control zone transfers.
| Example 5-6 Zone Transfer Options |
|---|
options {
max-transfer-time-in 120;
transfer-format one-answer;
transfers-in 10;
transfers-per-ns 2;
};
|
Table 5-9 describes the periodic task options.
| Option | Description |
|---|---|
| cleaning-interval | The server removes expired resource records from the cache every cleaning-interval minutes. The default is 60 minutes. If set to 0, no periodic cleaning occurs. |
| interface-interval | The server scans the network interface list every interface-interval minutes to see if interfaces have been added or deleted. The default is 60 minutes. If set to 0, only interface scanning occurs when the configuration file is loaded. After the scan, listeners are started on any new interfaces (provided they are allowed by the listen-on configuration). Listeners are deleted for any interface that has gone away. |
| statistics-interval | Name-server statistics are logged every statistics-interval minutes. The default is 60. If set to 0, no statistics are logged. |
If other settings are the same, when the server chooses a name server to query from a list of name servers, it chooses 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; the closer the match is to the start of the list, the shorter the distance is between the match and the server. A negated match is assigned the maximum distance from the server. If there is no match, the address gets a distance that is further than any non-negated list element and closer than any negated element.
In the following example, the server prefers 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.
topology {
10/8;
!1.2.3/24;
{ 1.2/16; 3/8; };
};
|
The default topology is as follows:
topology { localhost; localnets; };
|
Zone transfers can put a heavy load on network traffic and on a BIND server. If you have a large network with many BIND servers, keeping each server up-to-date can put a strain on the master server and its memory requirements. You can use the server statement to control the number of zone transfers that can occur and the duration of the zone transfer.
The server statement defines characteristics to be associated with a remote name server. The statement has the following syntax:
server ip_address {
[ bogus yes_or_no; ]
[ transfers number; ]
[ transfer-format ( one-answer | many-answers
) ; ]
[ keys { key_id [key_id ... ] }; ]
};
|
You can limit the number of zones your name server requests from a single remote name server by including a transfers substatement on the server statement. The default limit is two active zone transfers per name server. When your name server completely receives one of the two zone transfers, if another request is needed, the request will be sent after waiting a period of time.
Example 5-7 shows how to code the server statement to limit the number of transfer requests to name server 16.168.1.2 to three at a time.
| Example 5-7 Server Statement |
|---|
server 16.168.1.2 {
transfers 3
};
|
The BIND 8 transfer-format subcommand specifies how your name server transfers zone data to its slaves. The server can transfer one resource record in each DNS message ( one-answer ) or it can transfer as many records as possible into a single DNS message ( many-answers ). Using the many-answers method takes less bandwidth to transfer the same amount of data as the one-answer method and also uses less CPU time to decouple the DNS messages.
Example 5-8 shows how to code the server statement to send more than one record in the same DNS message to name server 16.168.1.2.
| Example 5-8 Server Statement |
|---|
server 16.168.1.2 {
transfer-format many-answers;
};
|
The zone statement defines zones maintained by the name server. The statement has the following syntax:
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 }; ]
[ notify yes_or_no; ]
[ forward ( only | first ); ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
};
zone domain_name [ ( in | hs | hesiod | chaos ) ] {
type ( slave | 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 }; ]
[ max-transfer-time-in number; ]
[ notify yes_or_no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
};
zone "." [ ( in | hs | hesiod | chaos ) ] {
type hint;
file path_name;
[ check-names ( warn | fail | ignore ); ]
};
|
BIND 8.1 uses address match lists for security. Address match lists are lists of elements that can include the following:
The ACLs any , none , localhost , and localnets are predefined. Elements can be negated with a leading ! .
When a given IP address or prefix is compared to an address match list, the list is traversed in order, and the first match (regardless of negation) is used. The interpretation of a match depends on whether the list is being used for access control or as a topology.
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 , and allow-update all use address match lists like this. Similarly, the listen-on clause can use negation to define local addresses that should not be used to accept name server connections.
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 the match and the server.) A negated match is assigned the maximum distance from the server. If there is no match, the address gets a distance that 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 one is negated. For
example, in
1.2.3/24; ! 1.2.3.13;
the
1.2.3.13
element is useless because the algorithm matches 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 ignores all the other
1.2.3.*
hosts.
5.3.6 Dynamic Updates
BIND 8.1 includes support for dynamic updates as specified in RFC 2136 (excluding support for the security mechanism described by RFC 2137). Any update requests received from hosts that are on the server's allowed list are honored. Dynamic updates allow the addition or deletion of resource records (RR) and RR sets from a specified zone.
By default, BIND 8.1 servers reject all dynamic update requests. This is a security mechanism that gives the zone administrator the ability to decide which hosts can submit dynamic updates. You specify the hosts from which a server will process requests by using the allow-update substatement. The allow-update substatement is applicable to a zone. You cannot specify this substatement as part of an options statement.
The syntax of the allow-update substatement is as follows:
allow-update { address_match_list } ;
|
The following example shows the use of the allow_update substatement:
zone "FRED.PARROT.BIRD.COM" in {
type master;
file "FRED_PARROT_BIRD_COM.DB";
allow-update {
99.1.2.3;
99.4.5.6;
}
}
|
IP addresses, IP prefixes, ACLs, and IP address match lists are all valid elements for the allow-update substatement.
When dynamic updates are sent to and accepted by a name server, the name server does the following:
Typically, a system administrator adds comments to the domain_name.DB file to provide history and helpful information pertinent to the data in the file, and formats the file for easy reading. With DNS dynamic updates enabled, all comments, formatting, and ordering will be lost.
TCP/IP Services provides two methods to prevent this:
The BIND server is able to detect a situation in which dynamic updates might be lost. When this happens, the server creates a new version of the domain_name.DB_LOG_BCK file containing the dynamic updates that would have been lost. The system administrator must review the transactions in the file and determine whether the updates are still valid and if so, manually apply the updates to the domain_name.DB file.
There is always at least one version of the domain_name.DB_LOG_BCK file when dynamic updates are enabled. Each time the BIND server detects lost updates, the server creates a new version of the domain_name.DB_LOG_BCK file. The existence of more than one of these files is a signal to the system administrator that manual merges may be necessary.
The server does not automatically purge the
domain_name.DB_LOG_BCK files, but the system administrator can
delete them after examining and applying their contents.
5.3.6.2 Manually Creating Updates
You can manually create updates to the domain database file using the command line utility NSUPDATE if the name server for the domain is configured to accept dynamic updates.
The format of the NSUPDATE command is:
NSUPDATE [ -d ] [ -v ] [ file-name ] |
In this format:
| -d | Specifies debug mode. |
| -v | Specifies that NSUPDATE uses the TCP protocol instead of the UDP protocol. |
| file-name | Specifies a file name containing update requests and entries. |
Table 5-10 shows the valid update commands for NSUPDATE .
| Command | Description |
|---|---|
| prereq yxrset domain_name type [ rdata] | Makes the presence of an RR set of type owned by domain_name a prerequisite to performing the update. |
| prereq nxrrset | Makes the nonexistence of an RR set of type owned by domain_name a prerequisite to performing the update specified in successive update commands. |
| prereq yxdomain domain_name | Makes the existence of the specified domain_name a prerequisite to performing the update. |
| prereq nxdomain | Makes the nonexistence of the specified domain name a prerequisite to performing the update |
| update delete domain_name [ type] [ rdata] | Deletes the specified domain name, or, if type is also specified, deletes the specified RR set, or, if rdata is also specified, deletes the record matching domain_name, type, and rdata. |
| update add domain_name ttl [ class] type rdata | Adds the specified record to the zone. Note that the TTL, in addition to the type and resource-record-specific data, must be included but class is optional and defaults to IN. |
NSUPDATE has two modes: interactive and noninteractive. In noninteractive mode, you supply the updates in a file. Data in the file must be in the following format:
class section name ttl type rdata |
In this format:
| class | Is any one of the following opcodes: update , zone , prereq . |
| section | Is any one of the following opcodes: add , delete , nxdomain , yxdomain , nxrrset , yxrrset . |
| name | Is the name of the entry being added. |
| ttl | Is time to live (in seconds) for this entry. After this time period, the name server will no longer serve the entry. |
| type | Specifies the RR type (for example, A, CNAME, NS, MX, TXT). |
| rdata | Specifies the data appropriate for the RR type being updated. |
The following example shows how to use NSUPDATE in the noninteractive mode.
$ TYPE NSUPD.TXT update delete www.nads.zn. update add www.nads.zn. 60 CNAME ivy18.nads.zn $ NSUPDATE NSUPD.TXT |
In interactive mode, you supply data in the format shown for noninteractive mode in response to each NSUPDATE prompt.
The following example shows how to use the NSUPDATE utility in interactive mode. The Resolver debug mode is enabled.
$ NSUPDATE > UPDATE ADD WWW.NADS.ZN 60 IN CNAME IVY18.NADS.ZN > res_mkupdate: packet size = 49 ;; res_send() ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 53349 ;; flags:; ZONE: 1, PREREQUISITE: 0, UPDATE: 1, ADDITIONAL: 0 ;; nads.zn, type = SOA, class = IN www.nads.zn. 1M IN CNAME ivy18.nads.zn. ;; Querying server (# 1) address = 192.168.1.1 ;; got answer: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 53349 ;; flags: qr ra; ZONE: 0, PREREQUISITE: 0, UPDATE: 0, ADDITIONAL: 0 |
When entering data in interactive mode, pressing Return (or Enter) with no data assumes the end of the input. NSUPDATE then processes all update entries in one operation. |
| Previous | Next | Contents | Index |