Configure a DNS Server

The configuration of each DNS server type is slightly different. In
this objective the following is discussed:
■ Configure a Caching-Only DNS Server
■ Configure a Master Server for Your Domain
■ Configure One or More Slave Servers

Configure a Caching-Only DNS Server
A caching-only DNS server does not manage its own databases but
merely accepts queries and forwards them to other DNS servers.
The replies are saved in the cache.
The DNS server configuration is defined in the file /etc/named.conf.
You can use the example file that is installed with the DNS package
as a configuration file for a caching-only server.
The following example shows the beginning of a simple
configuration:
Lines beginning with a hash sign (“#”) are comments and will be
ignored.
#
# /etc/named.conf: Configuration of the name server (BIND9)
#
# Global options
#
options
{
#
# In which directory are the database files?
#
directory "/var/lib/named";
};

The global options are defined in the options block at the beginning
of the file. The directory option specifies the directory where the
database files (or zone files) are located. Normally, this is
/var/lib/named/.
Using the directory option you can specify filenames for the
database files with a relative path (no absolute path required).
The global options are followed by the definition of the database
files for the domains managed by the DNS server. Several entries
are needed for basic DNS server functions such as those provided
by a caching-only server.
Three entries are needed for every DNS server:
■ The entry for root DNS servers (not needed for BIND 9 because
it has the list of root DNS servers compiled into the software).
■ The forward resolution for localhost
■ The reverse resolution for the network 127.0.0.0 (localhost)

The following are examples of these entries:
The zone entry for the root DNS servers contains a reference to a
file containing the addresses of the root DNS servers. This file
(root.hint) is generated in the directory /var/lib/named/ during the
installation of the package bind.
The two files for the resolution of localhost are also generated
during the installation. The structure of these files is explained later.
Starting each request for name resolution with queries to the root
servers can be quite slow. If these reqests are forwarded to a name
server with a lot of information in its cache (e.g., the name server of
your Internet service provider), the process will be much faster in
most cases.
## entry for root nameservers#
zone "." in {
type hint;
file "root.hint";
};
#
# forward resolution for localhost
#
zone "localhost" in {
type master;
file "localhost.zone";
};
#
# reverse resolution for localhost
#
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";

You can define these DNS servers in the options block in the file
/etc/named.conf, as in the following:
You can enter up to three DNS server addresses. Queries that
cannot be resolved by the local DNS server are forwarded to one of
the specified DNS servers.
If these DNS servers cannot be reached, the queries are sent directly
to the root DNS servers.
Configure a Master Server for Your Domain
The following are the tasks you need to do to configure a master
DNS server for your domain:
■ Adapt the Main Server Configuration File
■ Create the Zone Files
■ Create Additional Resource Records
Adapt the Main Server Configuration File
You can adapt the configuration of the caching-only DNS server to
configure a DNS server containing its own information files.
options
{
directory "/var/lib/named";
forwarders {
10.0.0.254;
};
};

This configuration already contains the global entries for the
directory and the forwarders entries (which can be omitted) in the
options block. There are also some more options marked as
comment. The file also contains the mandatory entries for the root
servers and the resolution of localhost.
The global options are followed by definitions for the database files
(or zone files) for the domains this DNS server serves. At least 2
files are necessary for each domain:
■ A file for forward resolution (allocating an IP address to a
computer name)
■ A file for reverse resolution (allocating a computer name to an
IP address)
If several subnets belong to a domain, then one file for each of these
networks must be created for reverse resolution.
Each definition begins with the instruction zone (this is why the
database files are also known as zone files), followed by the name
of this zone.
For forward resolution, this is always the domain name. For reverse
resolution, the network prefix of the IP address must be given in
reverse order (10.0.0. becomes 0.0.10.) to which the suffix
in-addr.arpa is added (0.0.10.in-addr.arpa).
The zone name is always followed by an “in” for Internet. (DNS
servers can administer information on different name spaces, not
only that of the Internet. Other name spaces are practically never
used.)
The text in curly brackets defines the type of DNS server type (e.g.,
master) for this zone and the name of the zone file.

The entries for a domain digitalairlines.com and a network
10.0.0.0/24 would look like this:
Create the Zone Files
The two files for the domain localhost and the file for the root DNS
servers are always included in the installation. You do not need to
change these files; however, you must create the files required for
the actual domain.
The subdirectory /var/lib/named/master/ is used for the database
files of a master server.
You need to know the following to manually create the zone files:
■ Structure of the Files
■ The File /var/lib/named/master/digitalairlines.com.zone
■ The File /var/lib/named/master/10.0.0.zone
■ The File /var/lib/named/master/localhost.zone
■ The File /var/lib/named/master/127.0.0.zone
#
# forward resolution for the domain digitalairlines.com
#
zone "digitalairlines.com" in {
type master;
file "master/digitalairlines.com.zone";
};
#
# reverse resolution for the network 10.0.0.0
#
zone "0.0.10.in-addr.arpa" in {
type master;
file "master/10.0.0.zone";
};

Structure of the Files
Each of the database files consists of a series of entries, or resource
records. The syntax of these records is always as follows:
reference [TTL] class type value
The following describes each part of a record:
■ reference. The reference to which the record refers. This can be
a domain (or subdomain) or a standalone computer (name or IP
address).
■ TTL. The Time To Live value for the record. If this is not
present, a default TTL value is used. This determines how long
other name servers store this information in their cache.
■ class. The class of the record. For TCP/IP networks, this is
always IN (internet).
■ type. The type of the record. The most important types are
listed in the table below.
■ value. The value of the record. The value depends on the type
of record as listed in the following:
Table 1-1 Record Type Meaning Value
SOA Start of Authority
(term for the
authority)
Parameters for the
domain
NS Name server Name or IP address of
one of the DNS servers
for this domain
MX Mail exchanger Name (or IP address)
and priority of a mail
server for this domain
A Address IP address of a computer
PTR Pointer Name of a computer

The File /var/lib/named/master/digitalairlines.com.zone
Unlike earlier versions of BIND, BIND 9 requires you to specify a
default TTL for all information at the beginning. This value is used
whenever the TTL has not been explicitly given for an entry.
You define the TTL with the following instruction:
x In this file, the semicolon is used as a comment sign.
In this example, the TTL is given in seconds. It can be given in
other units as well, such as 2D for two days. Other units are M
(minutes), H (hours), and W (weeks).
CNAME Canonical name Alias name for a
computer
Table 1-1 (continued) Record Type Meaning Value
;
; definition of a standard time to live, here: two days
;
$TTL 172800

This is followed by the definition of the SOA (Start of Authority)
entry, which specifies which DNS server has the authority for this
domain:
The domain to which this entry refers (in the example,
digitalairlines.com) is listed first. The domain name must end with
a dot. If a name does not have a trailing dot, the name of the domain
is added, which would lead to an error here.
The name of the DNS server is listed after the SOA entry (in this
example, da1.digitalairlines.com with a dot at the end).
Alternatively, you could write da1, and the domain name
digitalairlines.com would be added after the name.
Next comes the email address of the person who is responsible for
the administration of the DNS server. The “@” usually used in
email addresses must be replaced by a dot (so the email address in
this example is hostmaster.digitalairlines.com). This is necessary
because “@” has a special meaning as an abbreviation.
It is advisable to use a generic email address here (e.g.,
hostmaster@digitalairlines.com) instead of an individual email
address.
The next entry is a serial number. Any number can be used, but
normally the date and a version number are used here. After any
change to the data in this file, the serial number has to be increased.
;
; SOA Entry
;
digitalairlines.com. IN SOA da1.digitalairlines.com.
hostmaster.digitalairlines.com. (
2004092601; serial number
1D ; refresh (one day)
2H ; retry (two hours)
1W ; expiry time (one week)
3H ; "negative" validity (three hours)
)

Slave servers use this number to determine whether or not they need
to copy this zone file. If the serial number on the master server is
greater than that on the slave server, the file is copied.
The serial number is followed by time information (the first three
entries listed here are only important for slave servers):
■ The first entry causes a slave server to query a master server
after this length of time, to see if there is a new version of the
file (in the example, this is 1D or one day).
■ If the slave server cannot reach the master server, the next time
entry specifies at what intervals new attempts should be made
(in the example, this is 2H or two hours).
■ If the master server is not reached for a longer period of time,
the third time entry specifies when the slave server should
discard its information on this zone (in the example, this is 1W
or a week).
The basic idea here is that it is better not to pass on any
information than to pass on outdated information.
■ The fourth entry defines for how long negative responses from
the DNS server are valid. Each requesting server stores
responses in its cache, even if a computer name could not be
resolved (in the example, this is 3H or 3 hours).
These time definitions are followed by the name or IP address of the
computer that is acting as the DNS server for this domain. In all
cases, the master server must be entered here. If slave servers are
used, they should also be entered, as in the following:
The name of the domain can be omitted at this point. Then the name
from the previous entry (the SOA entry) is taken.
;
; entry for the name server
;
digitalairlines.com. IN NS da1.digitalairlines.com.
IN NS da2.digitalairlines.com.

At the end of this file are the IP addresses that are allocated to
computer names. This is done with A (address) entries, as in the
following:
The File /var/lib/named/master/10.0.0.zone
The file for reverse resolution contains similar entries as the file for
forward resolution. At the beginning of the file there is the
definition of a default TTL and an SOA entry.
;
; Allocation of IP addresses to host names
;
da10 IN A 10.0.0.10
da12 IN A 10.0.0.12
da13 IN A 10.0.0.13
...
da1 IN A 10.0.0.254
da2 IN A 10.0.0.2

In the SOA and NS entries, the IP address of the network is written
in reverse order:
At the end of this file are the host names that are allocated to
computer names, this time with the PTR (Pointer) entry, as in the
following:
; Database file for the domain digitalairlines.com:
; reverse resolution for the network 10.0.0.0
;
; Definition of a default TTL,here: two days
;
$TTL 172800
;
; SOA entry
;
0.0.10.in-addr.arpa. IN SOA da1.digitalairlines.com.
hostmaster.digitalairlines.com. (
2004092601; serial number
1D ; refresh (one day)
2H ; retry (two hours)
1W ; expiry time (one week)
3H ; "negative" validity(three hours)
)
;; Entry for the name server
;
IN NS da1.digitalairlines.com.
IN NS da2.digitalairlines.com.
;
; Allocation of host names to IP addresses
;
10 IN PTR da10.digitalairlines.com.
12 IN PTR da12.digitalairlines.com.
13 IN PTR da13.digitalairlines.com.
14 IN PTR da14.digitalairlines.com.
...
254 IN PTR da1.digitalairlines.com.
2 IN PTR da2.digitalairlines.com.

The following two files must exist for the local computer. These are
created automatically during installation and should not be
modified.
The File /var/lib/named/master/localhost.zone
The following is an example of the file
/var/lib/named/master/localhost.zone:
In this example, the “@” character is used as an abbreviation (for
this reason, it must be replaced by a dot in the email address in the
database files).
Using “@” instead of the domain name causes the file
/etc/named.conf to be read to see for which domain this file is
responsible.
In this case, it is localhost, which is also used for the name of the
DNS server (this is why “@” appears many times in the file).
$TTL 1W
@ IN SOA @ root (
42 ; serial (d. adams)
2D ; refresh
4H ; retry
6W ; expiry
1W ) ; minimum
IN NS @
IN A 127.0.0.1

The File /var/lib/named/master/127.0.0.zone
In this file, the abbreviation “@” is also used. But here the computer
name must be given explicitly with localhost (remember the dot at
the end):
Create Additional Resource Records
Apart from the resource records already discussed (SOA, NS, A,
PTR), there are MX and CNAME resource records, which are used
to do the following:
■ Define Mail Servers for the Domain
■ Assign Aliases for Computers
Define Mail Servers for the Domain
To be able to use email addresses in the form
geeko@digitalairlines.com, the email server responsible for the
domain must be defined (the email cannot be sent directly to the
domain, but must be sent to a mail server).
$TTL 1W
@ IN SOA localhost. root.localhost. (
42 ; serial (d. adams)
2D ; refresh
4H ; retry
6W ; expiry
1W ) ; minimum
IN NS localhost.
1 IN PTR localhost.

To achieve this, an MX (Mail Exchange) entry must be made in the
database file for forward resolution, after the DNS server entry:
If an email is now sent to the address geeko@digitalairlines.com,
the computer sending the mail asks the DNS server which computer
is the mail server, and is sent the list of the MX entries in return.
Several mail servers can be given. On the basis of their priorities, it
is then decided to which computer the email is sent. The priority of
mail servers is defined by the number next to MX; the lower this
number, the higher the priority.
In this example the computer mail.digitalairlines.com has the
highest priority (it is, therefore, the primary mail server).
da1.digitalairlines.com and da5.digitalairlines.com both have the
same priority.
If the mail server with the highest priority cannot be reached, the
mail server with the second-highest priority is used. If several mail
servers have the same priority, then one of them is chosen at
random. An address entry must be made for each mail server.
digitalairlines.com. IN MX 0 mail
IN MX 10 da1
IN MX 10 da5

Assign Aliases for Computers
If you want a computer to be reached by more than one name (such
as addressing a computer as da30.digitalairlines.com and
www.digitalairlines.com), then corresponding aliases must be
given.
These are the CNAME (canonical name) entries in the database file
for forward resolution:
x The names of the mail servers for the domain (MX entry) cannot be alias
names, since some mail servers cannot handle this correctly.
Configure One or More Slave Servers
To guarantee reliable operation, at least one more DNS server
besides the master server is required. This can take over part of the
load from the DNS master server. But it is especially important in
case the DNS master server is not available. This additional DNS
server is set up as a DNS slave server.
The essential difference between the two types is that a slave server
receives copies of the zone files from the master server.
Modifications to the zone files are only made on the master server.
As soon as a slave server is started, it connects to the master server
and receives a copy of the zone files from it. This is called a zone
transfer.
Comparison of data between the servers takes place automatically.
On the one hand, the slave server queries the master server at
regular intervals and checks, using the serial number of the zone
files, whether anything has changed.
da30 IN A 10.0.0.30
www IN CNAME da30

By default, the master server sends a message to all listed slave
servers (called notify) as soon as it has been restarted in order to
read in modified zone files.
In the configuration file /etc/named.conf for a slave server, there are
at least two entries that define it as a master server: the two zone
definitions for the loopback network (localhost).
There might also be a zone definition for the root DNS server. But a
zone definition is only necessary if the slave server will forward
requests to other DNS servers.
The definitions for zones for which it should copy data from the
master server look like the following:
The slave server gets data from the master server with the IP
address 10.0.0.254 and stores it in the directory
/var/lib/named/slave/. This directory is created when you install the
BIND package.
A similar configuration must be made for reverse resolution, as in
the following:
zone "digitalairlines.com" in {
type slave;
file "slave/digitalairlines.com.zone";
masters {
10.0.0.254;
};
};
zone "0.0.10.in-addr.arpa" in {
type slave;
file "slave/10.0.0.zone";
masters {
10.0.0.254;
};
};

In the simplest configuration, the slave server gets information from
the master server at regular intervals. This can cause the slave
server to provide outdated information for a certain length of time.
This is why it is reasonable to instruct the master server to inform
the slave servers about modifications in the database files. The slave
servers then immediately carry out a zone transfer, which always
brings them up to date.
In order for the master server to be able to communicate with the
slave servers, it must know about them. By default, the master
server automatically informs its slave servers. This can also be
defined explicitely in the options section of the file /etc/named.conf,
as in the following:
Subsequently, the slave servers must be listed as DNS servers in the
database files (for the forward and reverse resolution):
This informs the slave server, da8.digitalairlines.com, about all
modifications.
options {
...
notify yes;
};
digitalairlines.com. IN NS da1.digitalairlines.com.
IN NS da8.digitalairlines.com.

Ref. Novell Training Services (Course 3074)

Comments (0)

Subscribe to this comment's feed

Name

Email

Website

Title

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment