You get a bonus - 1 coin for daily activity. Now you have 1 coin

Installing and Configuring the BIND (named) DNS Server on CentOS (RedHat)

Practice



Task: install and perform the initial configuration of the bind DNS server (also known as named) on the Linux CentOS operating system (an OS from the RedHat family).

We will use chroot mode for bind to improve its security.


Installing

# yum install bind-chroot


It will pull in its parent package as well — bind.


Configuring

After installing the package, we suddenly become very interested in the folder:

/var/named/chroot/etc

This is exactly where named stores its configs in our chroot mode. So, for convenience of navigating there, let's create a symlink in /etc:

# cd /var/named/chroot/etc
# ln -s /var/named/chroot/etc /etc/named


That's it — now, once logged in to the server, we can browse named's settings via the convenient path

/etc/named


Now let's create the directory where the zone descriptions will live:

# mkdir master


Now we need to create the file /var/named/chroot/named.conf, which on RHEL systems isn't created automatically even with a minimal config. Well, let's do it by hand. Here's an example of such a config with explanations of what's what and why:

options {
directory "/var/named";

# Here you specify the DNS servers that this server will query in case
# it is not itself authoritative for the domain being resolved. Usually you
# specify your provider's DNS servers and/or your domain controllers' DNS servers.
# ..For example, if this server is asked what IP yandex.ru has, it won't
# know itself, but it will be able to ask the upstream provider's DNS server.
forwarders {
11.77.55.33;
11.77.55.34;
192.168.0.1;
};

# Where to accept DNS queries from. "any" means — from all interfaces, from any
# computer
allow-query { any; };

# Here you specify the slave DNS servers that are allowed to receive information
# when the DNS zones are updated on the current server.
allow-transfer {
11.22.33.45;
192.168.0.2;
};

# Here you specify the addresses or subnets from which recursive queries are allowed.
allow-recursion {
127.0.0.1;
192.168.0.0/24;
};

# When this option is enabled and any DNS zone changes on this server, it
# will automatically notify all slave servers that the zone has changed and
# needs to be reloaded.
notify yes;

# By default, only the server(s) listed as slave servers inside the zone's own
# description are notified. If you always have the same slave server(s), then it
# makes sense to list it/them here as servers that should always be notified about
# zone changes. In this case, even if these servers are not authoritative for those
# zones — nothing bad happens, they simply "ignore" the change notification.
# This option provides exactly that capability — to specify slave DNS servers
# that are always notified of zone changes.
also-notify {
11.22.33.45;
192.168.0.2;
};

auth-nxdomain no;

# Whether to listen for queries over IPv6 and from where? "none" means — do not
# expect any and ignore them; "any" means expect them from all hosts.
listen-on-v6 { none; };

};

include "/etc/zones.conf";


Now let's create the file /var/named/chroot/etc/zones.conf

Yes, that's right, exactly that one. Under chroot it will be at the path /etc/zones.conf, so everything is fine.

This file will hold the declarations of our zones.

To test our server, let's fill in the contents of the file like this:

zone "test.int" {
type master;
file "/etc/master/test.int";
};


Now let's head over to the directory

/var/named/chroot/etc/master/

where our DNS zone configurations will be located, and create the file "test.int"

# cd /var/named/chroot/etc/master
# touch test.int


with the following contents:

$ORIGIN .
$TTL 3600
test.int. IN SOA ns1.mydomain.ru. webadmin.mydomain.ru. (
2011080901 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS ns1.mydomain.ru.
NS ns2.mydomain.ru.
A 192.168.0.50
MX 10 mail.mydomain.ru.

$ORIGIN test.int.
ftp A 192.168.0.51
mail A 192.168.0.3
www CNAME test.int.


Save the file and close it.


Starting and checking

Let's start our daemon and check whether it's working.

# /etc/init.d/named start


and check:

# nslookup test.int 127.0.0.1


If in the response we get something like this:

Server: 127.0.0.1
Address: 127.0.0.1#53

Name: test.int
Address: 192.168.0.50


Then our server is working.


The DNS server's further life

All the other zones are created in the same way, this time with real details (for example, from the .ru, .com, etc. zones). The named.conf.zones file looks roughly like this:

zone "mydomain.ru" {
type master;
file "/etc/bind/master/mydomain.ru";
};

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


And for each zone we create a file with its configuration in /var/named/chroot/etc/master similar to the test.int sample configuration.


PS. Tip. Do NOT forget to put a ";" in the named config everywhere it's needed! Missing even one such semicolon will break the startup of the entire bind.

PPS. Do NOT forget to put the trailing dot "." at the end of zones that are absolute (recommended pretty much everywhere). That is, for example, if instead of "test.int." you write "test.int" in the zone config — you will get something completely different from what you expected! And accordingly, it simply won't work.

PPPS. Whenever you change a zone (any change) — don't forget to increment its serial number. And not just change it — specifically increment it. In this case a notation of the form YYYYMMDDNN, where YYYY is the 4-digit year, MM is the 2-digit month, DD is the 2-digit day, and NN is "how many times have I changed the zone today" — is quite convenient, since its numeric value will only ever increase over time.



Slave servers

In case you need to immediately set up a slave (secondary) DNS server as well — see the corresponding article.

Applies to: CentOS 5.6+

See also

  • [[b11054]]
  • [[b11032]]
  • [[b11052]]

See also

Comments

To leave a comment

If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Lectures and tutorial on "Running server side scripts using PHP as an example (LAMP)"

Terms: Running server side scripts using PHP as an example (LAMP)