Advanced Configuration of BIND 9

Advanced Configuration of BIND 9

Resend

Directory on this page
Advanced Configuration of BIND 9
ACL
Define ACL
Use ACL
ACL example
Use view to separate internal and external server configurations
About separating internal and external servers
View statement
BIND 9 log
Common bind log terms
Logging statement syntax
Run BIND 9 in the chroot jail Environment
Stop running the BIND server
Create a chroot jail Environment
Modify the default bind startup parameters
Add bind System Log Path
Restart bind9 and sysklogdtags: Ubuntu, dapper, netdeskrv, bind, ACL, view, logging, chroot

«Sitemap
«Dapper «netdeskrv

Advanced Configuration of BIND 9
Contents

Define and use the access control list
Use view configuration to separate internal and external servers
BIND 9 log Configuration
Run BIND 9 in the chroot jail Environment
ACL
The access control list (ACL) is a named address match list. The use of the access control list can make the configuration simple and clear, and can be used in multiple places after a definition, without confusing the configuration file because of a large number of IP addresses.

Define ACL
To define the access control list, you can use the ACL statement in the BIND main configuration file/etc/bind/named. conf. The ACL statement syntax is:

ACL acl_name {
Address_match_list;
};
By default, bind predefines the address matching list of four names, which can be used directly, respectively:

Any: All Hosts
Localhost: Local Machine
Localnets: all hosts on the local network
None: does not match any host

ACL is a top-level statement in named. conf and cannot be embedded into other statements.
To use a user-defined access control list, it must be defined before use. Because the access control list can be used in the options statement, the ACL statement that defines the access control list should be located before the options statement.
To facilitate the maintenance of the access control list defined by the Administrator, all ACL statements can be stored in a separate file/etc/bind/named. conf. in ACLs, and then in the main configuration file/etc/bind/named. the following statement in conf:

Include "/etc/bind/named. conf. Options ";
Add the following configuration lines

Include "/etc/bind/named. conf. ACLS ";

Use ACL
After the ACL is defined, you can use

Clause statement description
Allow-query options: Zone specifies which host or network can query the current server or zone. By default, all hosts are allowed to query.
Allow-transfer options, zone specifies which hosts are allowed to transfer the domain with the local server. The default value is to allow domain transfer with all hosts.
Allow-recursion options specifies which hosts can perform recursive queries. If this parameter is not set, all hosts are allowed to perform recursive queries by default. Disable recursive queries on a host. This host cannot be blocked from querying data that already exists in the server cache.
Allow-update zone specifies which hosts are allowed to submit dynamic dns updates for the Primary Domain Name Server. By default, any host is rejected for update.
Blackhole options specifies which hosts do not receive query requests and address resolution. The default value is none.

The configuration clauses listed above can appear both in the global configuration options statement and in the Zone Declaration statement. When both clauses appear at the same time, the configuration in the Zone Declaration statement overwrites the configuration in the global configuration options statement.
ACL example
Restricted Query
If you want to restrict only 202.0.0.0/8 and 221.0.0.0/8 to query information in all regions of the local server, you can use the following allow-query clause in the options statement.

Options {
......
Allow-query {202.0.0.0/8; 221.0.0.0/8 ;};
......
};
The preceding configuration does not use ACL. To use ACL, perform the following steps:

S1 adds the following ACL statement to/etc/bind/named. conf. ACLs to name the host list that can be queried.

ACL aqlist {
202.0.0.0/8;
221.0.0.0/8;
};
S2 limits the list of hosts that can be queried using the defined acl_name in/etc/bind/named. conf. Options.

Options {
......
Allow-query {aqlist ;};
......
};
Restricted Area Transmission
To limit that only 221.3.131.5 and 221.3.131.6 can transmit "example.com" information from the local server, use the following allow-transfer clause in the zone statement.

Zone "example.com "{
Type master;
File "example.com. hosts ";
Allow-transfer {221.3.131.5; 221.3.131.6 ;};
};
The preceding configuration does not use ACL. To use ACL, perform the following steps:

S1 adds the following ACL statement to/etc/bind/named. conf. ACLs to name the host list that can be queried.

ACL atlist {
221.3.131.5;
221.3.131.6;
};
S2 uses the defined acl_name in/etc/bind/named. conf. Local to restrict the list of hosts allowed for domain transfer.

Zone "example.com "{
Type master;
File "example.com. hosts ";
Allow-transfer {atlist ;};
};
Prevent spoofing and denial of service attacks
To prevent spoofing and DoS attacks, each DNS server on the Internet should have at least one false address ACL and one local address ACL. To do this, follow these steps:

S1 Add the following ACL statement to/etc/bind/named. conf. ACLs:

// Create an ACL named "bogusnets" to block the rfc1918 address space that is often used for fraudulent attacks.

ACL bogusnets {
0.0.0.0/8;
1.0.0.0/8;
2.0.0.0/8;
169.254.0.0/16;
192.0.2.0/24;
224.0.0.0/3;
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};

// Create an ACL named "Our-nets" and configure it as the actual IP address segment of this website.

ACL our-nets {// Replace the following address list with your network address
X. x/24;
X. x/21;
};
S2 limits query and response by using the defined acl_name in/etc/bind/named. conf. Options

Options {
......
Allow-query {our-nets ;};
Allow-recursion {our-nets ;};
Blackhole {bogusnets ;};
......
};
Use view to separate internal and external server configurations
About separating internal and external servers
Many sites want DNS to look different for Intranet access and Internet access. This type of configuration is called "separated DNS (split DNS )".

This configuration can be used in the following scenarios:

Expose all hosts in the entire zone to intranet users; only a few hosts, such as WWW servers, to Internet users
Specify different RR for internal and external users, or provide more RR for Intranet users
You can use the private address defined in RFC 1918 on the Intranet.
View statement
In BIND 9, you can use the view statement to separate DNS configurations. The view statement syntax is

View view_name {
Match-clients {address_match_list };
[View_option;...]
Zone_statement ;...
};
Where:

The match-clients clause is very important. It is used to specify who can see this view.
You can use some options in the view statement. For details, refer to the manual page of named. conf.
The zone_statement clause specifies the partition declaration visible in the current view.

If the view statement is used in the configuration file, all the zone statements must appear in the view.
For the same zone, the view configured for the Intranet should be placed before the view on the Internet.

The following is an example of using the view statement, which is taken from the bind9 document.

View "internal "{
Match-clients {our-nets ;}; // match the access requests of Intranet customers
Recursion yes; // allow recursive queries to customers on the Intranet
Zone "example.com" {// defines the Zone Declaration visible to the Intranet customer
Type master;
File "example.com. Hosts. Internal ";
};
};

View "external "{
Match-clients {Any ;}; // match the Internet client's access
Recursion no; // recursive query is not allowed for Internet customers
Zone "example.com" {// defines the Zone Declaration visible to Internet customers
Type master;
File "example.com. Hosts. External ";
};
};
Next, create a zone file visible to the Intranet client in example.com. Hosts. Internal, and create a zone file visible to the Internet client in example.com. Hosts. External. You can write these two files according to your actual situation.

BIND 9 log
By default, bind9 writes log messages to the/var/log/messages file, and these log messages are very few, mainly started, closed logs and some serious error messages, and write the debug log information to the named in the working directory of the BIND server. run file.

BIND 9 logs can be flexibly configured. to record the running status of the server in detail, you must use the logging statement in the configuration file named. conf to customize the log records you need.

Common bind log terms
Before describing the syntax of a logging statement, you must familiarize yourself with some common terms.

Glossary
Channel log output mode, such as syslog, text file, standard error output, or/dev/null
The message category of a category log, for example, querying a message or dynamically updating a message.
Module refers to the name of the source module that generates messages.
Facility (device) syslog device name
Severity (severity) Severity Level of a message

Logging statement syntax
The syntax of the logging statement is:

Logging {
Channel channel_name {// define Channel
File LOG_FILE [versions number | unlimited] [size sizespec]; | syslog optional_facility; | NULL; | stderr;
// Define the output mode
Severity log_severity; // defines the message severity.
[Print-time boolean;] // whether to add a time prefix to a message. It is only used for file logs.
[Print-severity Boolean;] // whether to add the message severity prefix to the message
[Print-category Boolean;] // whether to add the message category name prefix to the message
};
CATEGORY category_name {// define a category
Channel_name;
......
};
};
When configuring logs, you must first define the channel and then assign data of different log categories to the specified channel for output.

The default configuration of BIND 9 is:

Logging {
// The default channel is used, so there is no channel definition section
Category "default" {"default_syslog"; "default_debug ";};
};
Channel statement
The channel statement is used to define a channel.

To specify where to send log data, you must choose one of the following four types:
File: output to a plain text file
LOG_FILE specifies a file name
Version specifies how many versions of the file are allowed at the same time. For example, if three versions (version 3) are specified, the query will be saved. log, query. log0, query. log1 and query. log2.
Size specifies the maximum file size. If only the size is set but no version is set, when the file size reaches the upper limit, the server stops writing data to the file. If the version is set, the server will perform a loop, for example, convert LOG_FILE to log_file.log1, log_file.log1 to log_file.log2, and then create a new log_file.log for writing.
Syslog optional_facility: The device name of syslog.
Daemon
From local0 to local7
Null: output to a null Device
Stderr: output to standard error output. The default value is screen.
The severity statement is used to specify the message severity level. The value of log_severity is (in descending order of severity ):
Critical
Error
Warning
Notice
Info
Debug [level]
Dynamic is a special value that matches the current debugging level of the server.

After a severity level is defined, the system records all messages that include this level and more serious levels than this level. For example, if the definition level is error, the information at the critical and error levels is recorded.
For the system administrator, it is generally enough to record it at the info level.

BIND 9 pre-fabricated the following four default channels;

Channel "default_syslog "{
Syslog daemon; // The Daemon device sent to syslog.
Severity Info; // only send the info and its higher priority information
};

Channel "default_debug" {// output is generated only when the debug level of the server is not 0.
File "named. Run"; // write the named. Run file in the working directory.
Severity dynamic; // logs are recorded based on the current debug level of the server.
};

Channel "default_stderr "{
Stderr; // write to stderr
Severity Info; // only send the info and its higher priority information

};

Channel "null "{
NULL; // discard all messages sent to this channel
};
CATEGORY statement
The category statement specifies which type of information to use or which channel outputs have been defined.

Available category names (category_name) in BIND 9 include:

Category Description
The client processes client requests.
Config configuration file analysis and processing.
Messages related to the BIND internal database are used to store zone data and cache records.
Default matches all categories of unspecified channels.
DNSSEC processes the response of the DNSSEC signature.
General includes all unclearly classified bind messages.
Lame-servers finds an error in authorization, that is, the server is incomplete.
Network operations.
The notify message is updated in Region y.
Queries query logs
Resolver name resolution, including recursive query information from the parser.
Security approval/non-approval requests.
Update a dynamic update event.
Xfer-in is transferred from the remote name server to the local name server.
Xfer-out is transferred from the local name server to the remote name server.

For example, to record the query message, you can add the following configuration in named. conf:

Logging {
Channel query_log {
File "query. log" versions 3 size 20 m;
Severity Info;
Print-time Yes;
Print-category Yes;
};
CATEGORY queries {
Query_log;
};
};
In this way, the server will create a query in the working directory (directory specified by the Directory statement, Ubuntu:/var/Cache/Bind. log File, and write the queries messages generated during the running process to this file.

Generally, after the BIND has made major changes, you should configure and monitor the log, which may also increase the log message level. Once it is stable, you can restore the configuration. Because logs occupy a lot of disk space, especially query logs.
Run BIND 9 in the chroot jail Environment
Based on security considerations, BIND 9 should be run in the chroot jail environment. The following describes how to configure BIND 9 in the/chroot/named jail environment.

Stop running the BIND server
Sudo/etc/init. d/bind9 stop create the chroot jail Environment
Create a chroot directory
Sudo mkdir-P/chroot/named
Sudo chmod-r 700/chroot
Sudo mkdir/chroot/named/etc
Sudo mkdir/chroot/named/dev
Sudo mkdir-P/chroot/named/var/Cache/Bind
Sudo mkdir-P/chroot/named/var/run/bind/run
Move the original/etc/Bind directory to/chroot/named/etc
Sudo mV/etc/bind/chroot/named/etc
Sudo ln-S/chroot/named/etc/bind/etc/Bind // create a symbolic link for the original location for future updates
Create a device and modify its permissions
Sudo mknod/chroot/named/dev/null C 1 3
Sudo mknod/chroot/named/dev/random C 1 8
Sudo chmod 666/chroot/named/dev/null
Sudo chmod 666/chroot/named/dev/random
Sudo chown-r BIND: bind/chroot/named/var /*
Sudo chown-r BIND: bind/chroot/named/etc/Bind
Modify the default bind startup parameters
Run the following command to modify/etc/default/bind9:

Sudo VI/etc/default/bind9 splits the following rows

Change Options = "-u bind"

Options = "-u bind-T/chroot/named" add bind System Log Path
Run the following command to modify/etc/init. d/sysklogd:

Sudo VI/etc/init. d/sysklogd:

Syslogd = "-u syslog" changed

Syslogd = "-u syslog-A/chroot/named/dev/log" restart bind9 and sysklogd
Sudo/etc/init. d/sysklogd restart
Sudo/etc/init. d/bind9 start for more information