Archive:Docs/Drafts/AdministrationGuide/Servers/DNSBIND/BINDConfiguration

DNS and BIND

Configuring BIND

Before you start named you need to create the main configuration file, /etc/named.conf. Zone database files are also be required.

/etc/named.conf

The /etc/named.conf file is the main configuration file for BIND. The first section is the options section. The following is an example options section. A complete /etc/named.conf file follows at the end of this section:

options {
directory "/etc/bind";
allow-query {any;};
recursion no;
pid-file "/var/run/named/named.pid";
zone-statistics yes;
statistics-file "/etc/bind/named­stats.log";
};

The directory directive tells named the default location of the zone database files. If you set directory "/etc/bind"; you will need to create the /etc/bind directory. The user running named requires read access to this directory, and depending on configuration needs, may require write access. This guide assumes that after you have configured the zone database files, named will not require write access to any zone database files. To increase security, place zone database files that require write access in a separate directory to zone database files that only require read access.

The allow-query directive controls who is able to send queries to the DNS server. Using allow-query {any;}; allows anyone to query your DNS server. This is not recommended - queries should be limited to systems on your own subnet. The following is an example that only allows systems in the 192.168.0.0/24 network to query the DNS server:

allow-query {192.168.0.0/24;};

The recursion directive controls the cache functionality. Using recursion no disables caching and will cause named to only return iterative responses. These responses are not stored in cache. If you want to cache queries run a separate caching-server. If that is not possible, limit who can perform recursive queries. This should be limited to the subnet you are on. The following is an example that only allow systems in the 192.168.0.0/24 network to perform recursive queries:

allow-recursion {192.168.0.0/24;};

Control the location of the named pid file using the pid-file directive. The default location is /var/run/named.pid, which by default, should not be writeable by the user running named. Create a directory under /var/run, for example, /var/run/named/, to store the named pid file and give the user you use to run named with write access to this directory. If you use another location other than the default, specify this location using the pid-file directive.

The zone-statistics directive controls whether the DNS server will collect statistically information. If this is set to yes you can view statics using the rndc stats command. These statstics are also used by tools such as dnsgraph, which can be downloaded here: [1]

Running the rndc stats command will write a file called named.stats under the directory specified with the directory directive. Control the location and the name of the statics file using the statistics-file directive.

Statistics file Permissions

If you used statistics-file "/etc/bind/named­stats.log"; in /etc/named.conf, run the following command as root to set the correct user and group for named-stats.log:

chown named:root /etc/bind/named-stats.log

Run the following command as root to set the correct mode:

chmod 660 /etc/bind/named-stats.log

If you are running SELinux, run the following command to set the correct SELinux context:

chcon -t named_cache_t /etc/bind/named-­stats.log

Configuring Zones

Use the zone directive to define zones. Zone database files contain Resource Records. There are many different types of Resource Records, such as A records which map a hostname to an IP address, CNAME records which are used to map aliases to real names (for example, FTP and WWW mapping to the same server which is running both services), and MX, Mail Exchanger records. This list is note exhaustive, but lists the main Resource Records you will use.

Providing recursive queries outside of your own domain requires a root hints zone. The zone database file for the root hints zone contains a list of top level nameservers. The following is an example root hints zone file in /etc/named.conf. Define zone files underneath the options section in /etc/named.conf:

zone "." {
type hint;
file "/etc/bind/root.hint";
};

The following is an example zone for testdomain.com:

zone "testdomain.com" {
type master;
allow-transfer {192.168.0.5;};
file "/etc/bind/db.testdomain.com";
};

The name of the zone is defined between the talking marks after zone, in this case the zone name is testdomain.com. The type master; option configures the server to be a master server, which means it is authoritative for this zone. If type is set to slave the zone data is transferred from a master server. If you are specifying a slave zone, you need to configure where the master server is using the masters directive. The following is an example slave zone which uses a master server with an IP address of 192.168.0.6:

masters {192.168.0.6;};

The allow-transfer option controls who can perform a zone transfer. Zone transfers are used to replicate zone database files between servers. Definitely restrict who can perform a zone transfer, as zone files are a fantastic point to build up a network topology of a remote network. Restrict zone transfers using IP addresses, as shown in the example testdomain.com zone.

Define the location of the zone database file using the file option. This file is not anything special, it is simply a text file.

Two other zones you may require are zones for localhost and reverse lookups. The first is an example of a localhost host zone:

zone "localhost" {
type master;
file "/etc/bind/db.127";
};

The following is an example reverse lookup zone for a 192.168.0.0/24 network:

zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.0.168.192.in-addr.arpa";
};

Reverse lookup zone files are used to support reverse lookups, which is resolving a hostname when given an IP address. A reverse lookup zone is not required.

The in-addr.arpa is a specially reserved domain to support reverse lookups. When a DNS query is performed, the namespace (for example, host.testdomain.com) is searched from right to left. If this was performed on an IP address you would never find the correct network or host:

Starting from the right will not work:
192.168.0.1

Reversing the order allows searching starting from in-addr.arpa:
1.0.168.192.in-addr.arpa

The following is a complete /etc/named.conf example:

options {
directory "/etc/bind";
allow-query {any;};
recursion no;
pid­file "/var/run/named/named.pid";
zone-statistics yes;
statistics-file "/etc/bind/named­stats.log";
};

zone "." {
type hint;
file "/etc/bind/root.hint";
};

zone "testdomain.com" {
type master;
allow-transfer {192.168.0.5;};
file "/etc/bind/db.testdomain.com";
};

zone "localhost" {
type master;
file "/etc/bind/db.127";
};

zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.0.168.192.in­addr.arpa";
};

These are the basic configuration options available in /etc/named.conf. For a complete listing please refer to [2]

/etc/named.conf Permissions

Run the following command as root to set the correct user and group for /etc/named.conf:

chown named:named /etc/named.conf

Run the following command as root to set the correct mode:

chmod 600 /etc/named.conf

If you are running SELinux, run the following command to set the correct SELinux context:

chcon -t named_zone_t /etc/named.conf

Zone Database Files

Zone database files are text files which contain Resource Records. The following is the example of the first section of a zone database file. A ; symbol is used for comments. White spaces will cause problems so use ; symbols if you require spacing. A complete zone database file follows at the end of this section:

$TTL 3D
@ IN SOA testdomain.com. hostmaster (
2007022601 ;serial number
8H ;refresh
2H ;retry
4W ;expiry time
1H ;minimum
)

The $TTL value defines the default time-to-live value for Resource Records that do not specify one. This sets the duration for how long a resource record is valid, in other words, how long a server can cache this information without having to make a request for it again.

The @ IN SOA defines the Start Of Authority (SOA). This means the Resource Records in this zone database file contain authoritative information. The @ stands for "replace with the zone name". Since version 9 of BIND this information can be obtained from /etc/named.conf, or it could be written as follows:

testdomain.com. IN SOA testdomain.com. hostmaster

hostmaster is an email address that you can be contacted on. It is important to note the . at the end of testdomain.com.. You must have a trailing . at the end of the domain specified in the SOA.

After the SOA a number of values are defined:

• The serial number 2007022601 follows a year:month:day:number of modifications that day syntax. The example 2007022601 stands for 2007, February 26, and the database file was modified twice that day. Every time a zone database file is modified you must modify the serial number. Secondary nameservers use this information to notice when configuration changes have occurred. The serial number of the zone file on the master server is compared to the serial number of the zone file on the secondary server. If the serial number on the master server is more recent, a zone transfer occurs.

• The refresh time defines how often a secondary server checks its zone database files against a master server.

• When a request or zone refresh fails, the retry value defines how long a secondary server waits before trying to contact a master server.

• If a secondary server is unable to contact a master server, the expiry time defines when the secondary server will discard all zone data.

• The minimum time can cause some debate. In earlier versions of BIND (4,8) this value set the default time-­to-­live on resource records which did not specify one. In BIND 9 the minimum time is used to define how long a negative answer is cached. A negative answer is the response to a query for a domain which does not exist. Caching negative answers has the same benefits as caching positive responses: decreased resolving time and reduced network bandwidth, as the process of queries and referrals explained earlier does not have to keep taking place once the negative answer is cached. The time-­to-­live on cached negative answers is the minimum value of the minimum time and the $TTL value. Since the maximum minimum value is 3 hours, this value will usually be used as the time-­to-­live for cached negative answers. For more information on negative answers visit [3]

Resource Records follow a name ttl class resource record parameter syntax. The following is an example of the Resource Records section of a zone database file:

; name - ttl - class - rr - parameter
;
@ IN NS testserver.testdomain.com.
@ IN MX 10 mail.testdomain.com.
localhost IN A 127.0.0.1
mail IN A 192.168.0.1
testserver IN A 192.168.0.1
testclient IN A 192.168.0.2
laptop IN CNAME test

Trailing Periods
When a period is appended at the end of a name, for example with the NS and MX records, BIND takes that name as the Fully Qualified Domain Name (FQDN). If a period is not used the zone name will be appended. For example, the testserver A record resolves to the FQDN of testserver.testdomain.com. If it were written as testserver. IN A then testserverwould be the FQDN, which probably is not what you want since there is no testserver global Top Level Domain.

The first Resource Record is an NS entry, which stands for nameserver. The NS entry for testserver.testdomain.com is the actual machine the DNS server is running on. You should have at least two nameserver entries. When you use the dig tool the results will have an authority section, which contains a list of namesevers. A referral has a list of nameservers to query, so without nameserver entries in Resource Records, queries would not be possible.

Note, there is also an A record for the NS entry. Nameservers in your own domain require an A record - these are known as glue records. Glue records hold the DNS system together. Without an A record the testserver.testdomain.com nameserver would not be found, and queries would fail.

The next entry is an MX (Mail Exchanger) record. MX records are used for routing mail. The 10 between the MX and the name of the mail server sets the preference value. The server with the lowest prefernce will have the highest priority. The following is an example of a network with two mail servers. Multiple MX records are good for mail backup incase one server fails:

@ IN MX 10 mail.foo.bar.
@ IN MX 20 backup.foo.bar.
;
mail IN A 192.168.0.1
backup IN A 192.168.0.2

The mail.foo.bar. server has a higher priority that the backup.foo.bar. server. If the mail.foo.bar. server failed, backup.foo.bar. would be used for mail. There are A records for both mail servers. An A record is required for mail and nameservers within your own domain.

The following is an example A Resource Record, with details following afterwards:

testserver IN A 192.168.0.1

The name on the left hand side of the Resource Record is the hostname, which in this case is testserver. A TTL value is not defined, so this record will get the default of 3 days which was defined at the beginning of the zone database file using the $TTL 3D option.

The IN class stands for Internet Protocol. This is the most common class and most likely the only class you will need for a basic DNS server.

The Resource Record is the type of record, for example A, CNAME, and MX. An A record is used to map a hostname to an IP address. You must only have one A record per hostname: many hostnames pointing to one IP address is fine, but mapping one hostname to multiple IP address will cause routing problems.

The parameter at the end, in this case 192.168.0.1, can be another alias or hostname, or an IP address.

The following is an example of a CNAME resource record, with details following afterwards:

testclient IN A 192.168.0.2
laptop IN CNAME testclient

CNAME records are used to map aliases or hostnames to real names defined in A records. In this example, the ping laptop command would return the same results as the ping testclient command. The following is an example of when CNAMEs can be useful. One server (testserver) is providing both WWW and FTP services:

testserver IN A 192.168.0.1
www IN CNAME testserver
ftp IN CNAME testserver

In both of these cases queries for www.testdomain.com and ftp.testdomain.com would direct you to the testserver (with the IP address of 192.168.0.1). However, using a CNAME record results in two lookups: one lookup is required for the CNAME, and another for the A record. Balance the use of CNAME records on heavily loaded servers as they will add more load. The following is a valid example of mapping different hostnames to one IP address, which may be better in high-load situations:

testserver IN A 192.168.0.1
www IN A 192.168.0.1
ftp IN A 192.168.0.1

The following is a complete zone database file:

$TTL 3D
@ IN SOA testdomain.com. hostmaster (
2007022601 ;serial number
8H ;refresh
2H ;retry
4W ;expiry time
1H ;minimum
)
@ IN NS testserver.testdomain.com.
@ IN MX 10 mail.testdomain.com.
localhost IN A 127.0.0.1
mail IN A 192.168.0.1
testserver IN A 192.168.0.1
testclient IN A 192.168.0.2
laptop IN CNAME test

Reverse Lookup Zone Database Files

The following is an example reverse lookup zone database file for a 192.168.0.0/24 network. The SOA section has not been included, since it is the same as the previous example. This example concentrates on the Resource Records:

@ IN NS testserver.testdomain.com.
;
1 IN PTR testserver.testdomain.com.
2 IN PTR testclient.testdomain.com.

PTR (Pointer) records are used in reverse lookup zone database files. PTR records are basically the same as an A record. The values (1,2) in front of the IN class are the host portions of the IP addresses. For example, the testserver.testdomain.com machine uses a 192.168.0.1 IP address. Since this is a 192.168.0.0/24 network, the last octet of the IP address is the host section - therefore a value of 1 is used here. To make it clearer, if a new machine named pc1, with an IP address of 192.168.0.15 was added to the network. The correct entry would be as follows:

15 IN PTR pc1.testdomain.com.

Use Fully Qualified Domain Names in reverse lookup zone files. Using the following example a query for pc1 would result in pc12.0.168.192.in-­addr.arpa trying to be resolved. This is not desirable:

15 IN PTR pc1

Localhost Zone Database File

The following is an example localhost zone database file. An NS and A record are required. Localhost queries can usually be resolved by the local machine, so are localhost zone is not necessary in all cases:

$TTL 3D
@ IN SOA localhost. root.localhost. (
2007022601
8H
2H
4W
1H
)
@ NS localhost.
@ A 127.0.0.1

Root Hints Zone Database File

The Root Hints zone database file contains a list of root level name servers. This file is used for queries outside of your own domain. Run the following command to create the root hints zone database file:

dig at e.root-servers.net . ns > /etc/bind/root.hint

Zone Database File Permissions

Once zone database files have been configured, it is recommended to only have read permission on them. Change into the directory containing the zone database files, and run the following command as root to set the correct user and group for each zone database file, replacing all instances of zone-database-name with the correct file name:

chown named:named <code>zone-database-name</code> <code>zone-database-name</code> <code>zone-database-name</code>

For example, if you used the database names from the previous steps, run the following command:

chown named:named root.hint db.testdomain.com db.127 db.0.168.192.in-­addr.arpa

To set read-only permissions, run the following command as root:

chmod 400 zone-database-name zone-database-name zone-database-name

If read and write permissions are required, replace chmod 400 with chmod 600. If you are running SELinux, run the following command as root on each zone database file to set the correct SELinux context:

chcon -t named_zone_t <code>zone-database-name</code> <code>zone-database-name</code> <code>zone-database-name</code>

Bind directory permissions

Run the following command as root to set the correct user and group for the /etc/bind/ directory:

chown named:named /etc/bind/

Run the following command as root to set the correct mode:

chmod 755 /etc/bind/

If you are running SELinux, run the following command to set the correct SELinux context:

chcon -t named_zone_t /etc/bind/

Administration Guide - TOC

Previous Page - Installing BIND

Next Page - Configuring Logging