“UbuntuHelp:BIND9ServerHowto”的版本间的差异

2010年5月19日 (三) 21:42的最新版本

文章出处:

https://help.ubuntu.com/community/BIND9ServerHowto

点击翻译:

English

请不要直接编辑翻译本页，本页将定期与来源同步。

Background

Note: There are some issues with this Howto, too numerable to fix quickly, and it requires bringing up to standard. I'm mentioning this to help anyone to avoid the unnecessary time trying to resolve their DNS, owing the the inconsistencies in this document, particularly if you're new to DNS configuration. One example is here... box IN A 192.168.1.10 ... in all other places, the document uses the machine name example ns. Here it changes to box.

Introduction

Domain Name Service (DNS) is an Internet service that maps IP addresses and fully qualified domain names (FQDN) to one another. In this way, DNS alleviates the need to remember IP addresses. Computers that run DNS are called name servers. Ubuntu ships with BIND (Berkley Internet Naming Daemon), the most widely deployed DNS server. This guide is aimed at people looking to learn how to configure and maintain a DNS server, such as for a network (caching name server) or to serve DNS zones for a domain name.

Installation

BIND9 is available in the Main repository. No additional repository needs to be enabled for BIND9. Before we begin, you should be familiar with RootSudo. To install the server simply install the bind9 package. See InstallingSoftware for details on using package managers. A very useful package for testing and troubleshooting DNS issues is the dnsutils package. Also, the BIND9 Documentation can be found in the bind9-doc package.

BIND9 Configuration Scenarios

BIND9 can provide many different DNS services. Some of the most useful setups are:

Caching Server

In this configuration BIND9 will find the answer to name queries and remember the answer for the next query. This can be useful for a slow internet connection. By caching DNS queries, you will reduce bandwidth and (more importantly) latency.

Primary Master Server

BIND9 can be used to serve DNS records (groups of records are referred to as zones) for a registered domain name or an imaginary one (but only if used on a restricted network).

Secondary Master Server

A secondary master DNS server is used to complement a primary master DNS server by serving a copy of the zone(s) configured on the primary server. Secondary servers are recommended in larger setups. If you intend to serve a registered domain name they ensure that your DNS zone is still available even if your primary server is not online.

Hybrids

You can even configure BIND9 to be a Caching and Primary Master DNS server simultaneously, a Caching and a Secondary Master server or even a Caching, Primary Master and Secondary Master server. All that is required is simply combining the different configuration examples.

Stealth Servers

There are also two other common DNS server setups (used when working with zones for registered domain names), Stealth Primary and Stealth Secondary. These are effectively the same as Primary and Secondary DNS servers, but with a slight organizational difference. For example, you have 3 DNS servers; A, B and C. A is the Primary, B and C are secondaries. If you configure your registered domain to use A and B as your domain's DNS servers, then C is a Stealth Secondary. It's still a secondary, but it's not going to be asked about the zone you are serving to the internet from A and B If you configure your registered domain to use B and C as your domain's DNS servers, then A is a stealth primary. Any additional records or edits to the zone are done on A, but computers on the internet will only ever ask B and C about the zone.

DNS Record Types

There are lots of different DNS record types, but some of the most common types are covered below.

Address Records

The most commonly used type of record. This record maps an IP Address to a hostname.

www      IN    A      1.2.3.4

Alias Records

Used to create an alias from an existing A record. You can create a CNAME record pointing to another CNAME record. But it doubles the number of requests made to the nameserver, thus making it an inefficient way to do so.

mail     IN    CNAME  www
www      IN    A      1.2.3.4

Mail Exchange Records

Used to define where email should be sent to and at what priority. Must point to an A record, not a CNAME. Multiple MX records can exist if multiple mail servers are responsible for that domain.

        IN    MX  10    mail.example.com.

        [...]

mail    IN    A       1.2.3.4

Name Server Records

Used to define which servers serve copies of this zone. It must point to an A record, not a CNAME. This is where Primary and Secondary servers are defined. Stealth servers are intentionally omitted.

        IN    NS     ns.example.com.

        [...]

ns      IN    A      1.2.3.4

Configuring BIND9

BIND9 Configuration files are stored in:

/etc/bind/

The main configuration is stored in the following files:

/etc/bind/named.conf
/etc/bind/named.conf.options
/etc/bind/named.conf.local

Caching Server configuration

The default configuration is setup to act as a caching server. All that is required is simply adding the IP numbers of your ISP's DNS servers. Simply uncomment and edit the following in /etc/bind/named.conf.options:

        [...]

        forwarders {
             1.2.3.4;
             5.6.7.8;
        };

        [...]

(where 1.2.3.4 and 5.6.7.8 are the IP numbers of your ISP's DNS servers) Now restart the bind daemon:

sudo /etc/init.d/bind9 restart

Testing

If you installed the dnsutils package you can test your setup using the dig command:

dig -x 127.0.0.1

If all goes well you should see output similar to:

; <<>> DiG 9.4.1-P1 <<>> -x 127.0.0.1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13427
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

[...]

;; Query time: 1 msec
;; SERVER: 172.18.100.80#53(172.18.100.80)
;; WHEN: Mon Nov 26 23:22:53 2007
;; MSG SIZE  rcvd: 93

The dig command can also be used to query other domains for example:

dig google.com

If you "dig" a domain name multiple times you should see a drastic improvement in the Query time: between the first and second query. This is due to the server caching the query.

Primary Master Server configuration

In this section BIND9 will be configured as the primary master for the domain example.com. Simply replace example.com with your fully qualified domain name.

Zone File

To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, all you have to do is edit named.conf.local:

        [...]

        zone "example.com" {
             type master;
             file "/etc/bind/db.example.com";
        };

        [...]

Now use an existing zone file as a template:

sudo cp /etc/bind/db.local /etc/bind/db.example.com

Edit the new zone file /etc/bind/db.example.com change localhost. to the FQDN of your server, leaving the additional "." at the end. Change 127.0.0.1 to the nameserver's IP Address and root.localhost to a valid email address, but with a "." instead of the "@". also leaving the "." at the end. Also, create an A record for ns.example.com the name server in this example:

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.example.com.
@       IN      A       192.168.1.10
box     IN      A       192.168.1.10

You must increment the serial number every time you make changes to the zone file. If you make multiple changes before restarting BIND9, simply increment the serial once. Now, you can add DNS records to the bottom of the zone. Tip: Many people like to use the last date edited as the serial of a zone, such as 2005010100 which is yyyymmddss (where s is serial) Once you've made a change to the zone file BIND9 will need to be restarted for the changes to take affect:

sudo /etc/init.d/bind9 restart

Reverse Zone File

Now that the zone file is setup and resolving names to IP Adresses a Reverse zone is also required. A Reverse zone allows DNS to convert from an address to a name. Edit /etc/bind/named.conf.local and add the following:

zone "1.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "/etc/bind/db.192";
};

Note: replace 1.168.192 with the first three octets of whatever private network you are using. Also, name the zone file db.192 in the example appropriately. Now create the db.192 file:

sudo cp /etc/bind/db.127 /etc/bind/db.192

Next edit /etc/bind/db.192 changing the basically the same options as in /etc/bind/db.example.com:

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.
10      IN      PTR     ns.example.com.

The serial number in the reverse zone needs to be incremented on each changes as well. For each A record you configure in /etc/bind/db.example.com you need to create a PTR record in /etc/bind/db.192. After creating the reverse zone file restart bind9:

sudo /etc/init.d/bind9 restart

Testing

You should now be able to ping example.com and have it resolve to the host configured above:

ping example.com

You can also use the named-checkzone utility that is part of the bind9 package:

named-checkzone example.com /etc/bind/db.example.com

and

named-checkzone example.com /etc/bind/db.192

This is a great way to make sure you haven't made any mistakes before restarting bind9. You can use the dig utility to test the reverse zone as well as the new domain name:

dig 1.168.192.in-addr.arpa. AXFR

You should see output resolving 1.168.192.in-addr.arpa. to your nameserver.

Secondary Master Server configuration

Once a Primary Master has been configured a Secondary Master is needed in order to maintain the availability of the domain should the Primary become unavailable. First, on the primary master server, the zone transfer needs to be allowed. Add the allow-transfer option to the sample Forward and Reverse zone definition in /etc/bind/named.conf.local:

        [...]

        zone "example.com" {
             type master;
             file "/etc/bind/db.example.com";
             allow-transfer { @ip_secondary; };
        };

        [...]

        zone "1.168.192.in-addr.arpa" {
             type master;
             notify no;
             file "/etc/bind/db.192";
             allow-transfer { @ip_secondary; };
        };

       [...]

Note: replace @ip_secondary with the actual IP Address of your secondary server. Next, on the Secondary Master, install the bind9 package the same way as the primary. Then edit the /etc/bind/named.conf.local and add the following declarations for the Forward and Reverse zones:

        [...]

        zone "example.com" {
             type slave;
             file "/var/cache/bind/db.example.com";
             masters { @ip_master; };
        };

        [...]

        zone "1.168.192.in-addr.arpa"; {
             type slave;
             file "/var/cache/bind/db.192";
             masters { @ip_master; };
        };

        [...]

Note: replace @ip_master with the IP Address of the Primary. The zone file must be in `/var/cache/bind/` because, by default, AppArmor only allows write access inside it (this was made specifically for a slave configuration. See AppArmor's configuration in `/etc/apparmor.d/usr.sbin.named`). Restart the server, and in /var/log/syslog you should see something similar to:

syslog.5.gz:May 14 23:33:53 smith named[5064]: zone example.com/IN: transferred serial 2006051401
syslog.5.gz:May 14 23:33:53 smith named[5064]: transfer of 'example.com/IN' from 10.0.0.202#53: end of transfer
syslog.5.gz:May 14 23:33:35 smith named[5064]: slave zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2006051401)

Note: A zone is only transfered if the Serial Number on the Primary is larger than the one on the Secondary.

Testing

Testing the Secondary Master can be done using the same methods as the Primary. Also, you could shutdown BIND9 on the Primary then try pinging example.com from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve example.com.

Chrooting BIND9

Chrooting BIND9 is a recommended setup from a security perspective if you don't have !AppArmor installed. In a chroot enviroment, BIND9 has access to all the files and hardware devices it needs, but is unable to access anything it should not need.  !AppArmor is installed by default on recent Ubuntu releases. Unless you've explicitly disabled !AppArmor, you might want to read this before you decide to attempt a chrooted bind. If you still want to go forward with it, you'll need this information, which isn't covered in the instructions that follow here. To chroot BIND9, simply create a chroot enviroment for it and add the additional configuration below

The Chroot Enviroment

Create the following directory structure

$ sudo mkdir -p /chroot/named
$ cd /chroot/named
$ sudo mkdir -p dev etc/namedb/slave var/run

Set permissions for chroot environment

$ sudo chown root:root /chroot
$ sudo chmod 700 /chroot
$ sudo chown bind:bind /chroot/named
$ sudo chmod 700 /chroot/named

Create or move the bind configuration file.

$ sudo touch /chroot/named/etc/named.conf

or

$ sudo cp /etc/named.conf /chroot/named/etc

Give write permissions to the user bind for /chroot/named/etc/namedb/slave directory.

$ sudo chown bind:bind /chroot/named/etc/namedb/slave

This is where the files for all slave zones will be kept. This increases security, by stopping the ability of an attacker to edit any of your master zone files if they do gain access as the bind user. Accordingly, all slave file names in the /chroot/named/etc/named.conf file will need to have directory names that designate the slave directory. An example zone definition is listed below.

zone “my.zone.com.” {
	type slave;
	file “slaves/my.zone.com.dns”;
	masters {
		10.1.1.10;
	};
};

Create the devices BIND9 requires

$ sudo mknod /chroot/named/dev/null c 1 3
$ sudo mknod /chroot/named/dev/random c 1 8

Give the user bind access to the /chroot/named/var/run directory that will be used to strore PID and statistical data.

$ sudo chown bind:bind /chroot/named/var/run

BIND9's Configuration

Edit the bind startup options found in /etc/default/bind9. Change the line the reads:

/etc/default/bind9:

OPTIONS=”-u bind”

So that it reads

/etc/default/bind9:


OPTIONS="-u bind -t /var/named -t /chroot/named -c /etc/named.conf"

The -t option changes the root directory from which bind operates to be /chroot/named. The -c option tells Bind that the configuration file is located at /etc/named.conf. Remember that this path is relative to the root set by -t. The named.conf file must also recieve extra options in order to run correctly below is a minimal set of options:

/chroot/named/etc/named.conf:

options {
    directory "/etc/namedb";
    pid-file "/var/run/named.pid";
    statistics-file "/var/run/named.stats";
};

Ubuntu's syslod Daemon Configuration

/etc/init.d/sysklogd:


        [...]

SYSLOGD="-u syslog -a /chroot/named/dev/log"

        [...]

(Author Note: Check this config)

Restart the syslog server and BIND9

$ sudo /etc/init.d/sysklogd restart
$ sudo /etc/init.d/bind9 restart

At this point you should check /var/log/messages for any errors that may have been thrown by bind.

Starting, Stopping, and Restarting BIND9

Use the following command to start BIND9 :

$ sudo /etc/init.d/bind9 start

To stop it, use :

$ sudo /etc/init.d/bind9 stop

Finally, to restart it, run

$ sudo /etc/init.d/bind9 restart

Status

To check the status of your BIND9 installation:

$ host localhost

or

$ dig @localhost

(where localhost is the system you are setting BIND9 up on. If not localhost, use the appropriate IP number.)

Logging

BIND9 has a wide variety of logging configuration options available. There are two main options to BIND9 logging the channel option configures where logs go, and the category option determines what to log. If no logging option is configured for the default option is:

logging {
     category default { default_syslog; default_debug; };
     category unmatched { null; };
};

Next we will configure BIND9 to send debug messages related to DNS queries to a separate file.

Channel Option

First, we need to configure a channel to specify which file to send the messages to. Edit /etc/bind/named.conf.local and add the following:

logging {
    channel query.log {
        file "/var/log/query.log";
        // Set the severity to dynamic to see all the debug messages.
        severity dynamic;
    };
};

Option

Next, configure a category to send all DNS queries to the query file:

logging {
    channel query.log {
        file "/var/log/query.log";
        // Set the severity to dynamic to see all the debug messages.
        severity debug 3;
    };

    category queries { query.log; };
};

Note: the debug option can be set from 1 to 3. If a level isn't specified level 1 is the default. Since the named daemon runs as the bind user the /var/log/query.log file must be created and the ownership changed:

sudo touch /var/log/query.log
sudo chown bind /var/log/query.log

Now restart BIND9 for the changes to take affect:

sudo /etc/init.d/bind9 restart

You should see the file /var/log/query.log fill with BIND9 log information. This is a simple example of the BIND9 logging options available see bind9.net manual for more information.

Additional Possibilities

You can monitor your BIND9 server usage by installing the bindgraph package from the Universe (To enable Universe - see AddingRepositoriesHowto) and following configuration details as outlined in bindgraph's README documents

Further Information

Online Recources

"ISC's BIND9 Manual" TLDP's "DNS HOWTO" (For General Overview) "Chroot BIND Howto" Debian BIND Wiki BIND reference guide

Printed Resources

"DNS & BIND" - Paul Albitz & Cricket Liu - 4th Edition - "O'Reilly Press" (Amazon.com) "DNS & BIND Cookbook" - Cricket Liu - 4th Edition - "O'Reilly Press" (Amazon.com)