SUSE Conversations


BIND DNS (Berkeley Internet Name Domain)



By: DamianMyerscough

May 14, 2008 12:36 pm

Reads:1970

Comments:0

Rating:0

In this article we are going to look at setting up and configuring the BIND DNS server, we will be configuring the BIND DNS server manually without using the YaST utility. The BIND DNS service is the most popular DNS server around. The BIND DNS server converts Full Qualifier Domain Names (FQDN) into their IP address and vice versa i.e. www.example.com translates to 208.77.188.166.

Installation

In this section of the article we will look at installing the BIND DNS server using the YaST utility. The YaST utility can be started by issuing the command yast sw_single which will provide a cruses based interface or you can issue the yast2 sw_single command which will provide you with a GUI (Graphical User Interface). Once you have decided which method you would like to use you will need to select the option “Filter” which is located in the top left corner. From the “Filter” combo box you should select “Patterns” and then select “DHCP and DNS Server”.

Once you have selected the “DHCP and DNS Server” you can select OK and then select “Accept” to begin the installation process.

Configuration files

Once the installation process has finished you can begin to configure your DNS server, but before doing so, we should look at what configuration files we will be working with. Table 1 lists the two configuration files that we will be working with and what they are used for.

Configuration file Description
/etc/named.conf This is the main configuration file that the BIND DNS uses. All global options are declared in this configuration file.
/etc/named.conf.include This configuration file may need to be created. This file just holds zone declarations. The reason for this is so that the named.conf file does not get over populated.

Table 1: BIND DNS Configuration files.

Before setting up and configuring a caching only nameserver we will first check to see if the named.conf.include file exists within the /etc directory, this can be done using two different commands. The first command that we will look at is test. The test command specified with the -e qualifier will check to see if a file exists as shown in Figure 1. The second command that you can use is ls followed by the path and name of the file, if the file exists the name will be echoed below the command.

server1:/etc # test -e /etc/named.conf.include 
server1:/etc # echo $?
1

Figure 1: Checking the named.conf.include file exists.

As you can see from Figure 1 the exit status from the previous command return the number 1 which means the file does not exist. To create the named.conf.include file you can simply issue the touch command as shown in Figure 1.1.

server1:/etc # touch /etc/named.conf.include

Figure 1.1: Creating an empty configuration file.

Once you have created the named.conf.include file you can begin to setup and configure the caching only nameserver.

Caching only nameserver

In this section of the article we are going to look at setting up a caching only nameserver. Setting up a caching only nameserver in SUSE Linux Enterprise Server 10 SP1 is very simple. There is only one step needed to setup a caching only nameserver and that is actually starting the BIND DNS server. This can be done simply by issuing the service command as shown in Figure 2 or by issuing the rcnamed command.

server1:/etc # service named start 
Starting name server BIND                                             done

Figure 2: Starting the BIND DNS server.

Once the BIND DNS server has been started your caching only nameserver will be ready for use by clients on your network. As I stated earlier, setting up a caching only nameserver is very simple. On your clients machine you will need to edit the resolv.conf file which is located within the /etc directory, this file will need the IP address of your caching only nameserver as shown in Figure 2.1.

nameserver 192.168.0.1

Figure 2.1: /etc/resolv.conf file entry.

Now that you have setup a caching only nameserver we will look at some of the directives which are specified in the named.conf configuration file. Table 2 explains some of the directives that are stored in the named.conf configuration file.

Directive Description
directory “/var/lib/named”; This directive states where the BIND DNS working directory is located.
listen-on port 53 { 127.0.0.1; }; This directive specifies BIND’s port number along with the IP address it should listen on.
allow-query { 127.0.0.1; }; This directive allows you to specify who is allowed to query the DNS server.
notify no; This directive, if set to yes, will send notification messages when a zone file has been changed.
include “/etc/named.conf.include”; This directive tells BIND what files to include, this entry is so that the named.conf file does not get over populated with zone file entries.

Table 2: named.conf directives explained.

Authoritative Nameserver

In this section of the article we will look at configuring an authoritative nameserver. Setting up an authoritative nameserver is more complex than setting up a caching only nameserver. In this article we are going to create a FQDN which will be example.com and will translate to the IP address of 192.168.2.141.

The first step is to create two zone definitions in the named.conf.include file as shown in Figure 3. The first entry is for the FQDN and the second entry is for reverse lookup i.e. Translating IP addresses into FQDN.

zone "example.com" in { 
        type master; 
        file "master/example.com.zone"; 
}; 

zone "2.168.192.in-addr.arpa" in { 
        type master; 
        file "master/192.168.2.zone"; 
};

Figure 3: named.conf.include zone definitions.

As you can see in Figure 3 the entry “2.168.192.in-addr.arpa” is the part of the IP address in reverse for the example.com domain. You should notice that the last octal digits are left off. Table 3 explains the syntax of a zone definitions.

Zone definition entry Description
zone “example.com” in { This section defines the name of the zone and also starts the zone definition which will house certain directives for the zone.
type master; This section defines the type for the zone, this can either be master or slave. When you setup a master and slave you need to specify the type as slave of the slave server.
file “master/example.com.zone”; This section specifies the name and location of the zone file.
}; This section terminates the zone block.

Table 3: Zone definitions explained.

Once you have added the zone definitions to the named.conf.include you will need to create two zone files which are explained in the next section.

Creating and configuring zone files

In this section of the article we will need to create two zone files. However, we do not need to create them from scratch because we can use the local loop back zone file and just modify it to suite our needs. The local loop back zone file is located within the /var/lib/named directory and is called: “localhost.zone”, this file needs to be copied into the /var/lib/named/master directory and renamed to the zone file which was specifies within the named.conf.include file as shown in Figure 4.

server1:~ # cp /var/lib/named/localhost.zone /var/lib/named/master/example.com.zone

Figure 4: Creating a copy of the local loop back zone file.

Once the zone file has been successfully copied to /var/lib/named/master you need to edit the zone file to suite your needs. Figure 4.1 shows the zone file used in this article and Table 4 explains each section of the zone file.

$TTL 1W 
@               IN SOA  example.com.    root.example.com. ( 
                                0605200803      ; serial (d. adams) 
                                2D              ; refresh 
                                4H              ; retry 
                                6W              ; expiry 
                                1W )            ; minimum 

                IN NS           example.com. 

example.com.    IN A            192.168.2.141 
example.org.    IN A            192.168.2.142 

www             CNAME           example.com.

Figure 4.1: Example zone file.

Zone line entry Description
$TTL 1W TTL specifies the time to live for all records in the zone that do not have an explicit TTL.
@ IN SOA example.com. root.example.com. ( This section specifies the State Of Authority. The fourth field (example.com) states where the zone file comes from and the fifth field (root.example.com) specifies the administrators email address.
0605200803 ; serial (d. adams) This entry specifies the serial number. The serial number is used for determining if the zone has changed on master servers (so slave servers do not always need to synchronize the entire zone).
2D ; refresh Refresh sets how often the zone should be synchronized from master name server to slave name servers” (YaST Utility, 2008).
4H ; retry Retry sets how often slave servers try to synchronize the zone from the master server if synchronization fails.
6W ; expiry Expiration means the period after which the zone expires on slave servers and slave servers stop answering replies until it is synchronized.
1W ) ; minimum Minimum sets the duration the slave servers should cache negative answers (name resolution failed).
IN NS example.com. This section specifies the nameserver resource record.
example.com. IN A 192.168.2.141 This section specifies an A (address) record which will convert example.com into 192.168.2.141.
example.org. IN A 192.168.2.142 This section specifies an A (address) record which will convert example.org into 192.168.2.142.
www CNAME example.com. CNAME: Alias for Domain Name: Record Key is a hostname relative to the current zone or a fully qualified hostname followed by a dot. Value is a hostname relative to the current zone or a fully qualified hostname followed by a dot. It must be represented by an A record” (YaST utility, 2008).

Table 4: Zone file explained.

Once you are happy with the zone file you need to create a reverse zone file. This can be done by making a copy of the local loop back reverse zone file. The local loop back reverse zone file is stored within the /var/lib/named directory and is called: “127.0.0.zone“. This file needs to be copied into the /var/lib/named/master directory and renamed as shown in Figure 4.2. The name should be identical to the one you specified in the zone definition.

server1:~ # cp /var/lib/named/127.0.0.zone /var/lib/named/master/192.168.2.zone

Figure 4.2: Creating a copy of the local loop back reverse zone file.

Once you have copied the reverse zone file you will need to modify it to suite your needs. Figure 4.3 shows the reverse zone file modified for the example.com domain.

$TTL 1W 
@               IN SOA          example.com.   root.example.com. ( 
                                0605200801      ; serial (d. adams) 
                                2D              ; refresh 
                                4H              ; retry 
                                6W              ; expiry 
                                1W )            ; minimum 

                IN NS           example.com. 
141             IN PTR          example.com.

Figure 4.3: example.com reverse zone file.

As you can see in Figure 4.3 it is very similar to the example.com.zone file, the only difference is the last line. Table 5 explains the last line shown in Figure 4.3.

Column Description
141 This specifies the ending of the IP address i.e. 192.168.2.141.
IN PTR This indicates that we are using a pointer record.
example.com. This specifies the address we are pointing to.

Table 5: example.com reverse lookup explained.

Once you are happy with your configuration file you can start the BIND DNS server using the service command as shown in Figure 2. When the BIND DNS server has been started you can check the /var/log/messages file to see if it was started successfully as shown in Figure 4.4.

May  6 15:53:50 server1 named[7332]: starting BIND 9.3.4 -t /var/lib/named -u named 
May  6 15:53:50 server1 named[7332]: found 1 CPU, using 1 worker thread 
May  6 15:53:50 server1 named[7332]: loading configuration from '/etc/named.conf' 
May  6 15:53:50 server1 named[7332]: listening on IPv6 interfaces, port 53 
May  6 15:53:50 server1 named[7332]: listening on IPv4 interface lo, 127.0.0.1#53 
May  6 15:53:50 server1 named[7332]: listening on IPv4 interface eth0, 192.168.2.141#53 
May  6 15:53:50 server1 named[7332]: command channel listening on 127.0.0.1#953 
May  6 15:53:50 server1 named[7332]: command channel listening on ::1#953 
May  6 15:53:50 server1 named[7332]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42 
May  6 15:53:50 server1 named[7332]: zone 2.168.192.in-addr.arpa/IN: loaded serial 605200801 
May  6 15:53:50 server1 named[7332]: master/example.com.zone:12: ignoring out-of-zone data (example.org) 
May  6 15:53:50 server1 named[7332]: zone example.com/IN: loaded serial 605200803 
May  6 15:53:50 server1 named[7332]: zone localhost/IN: loaded serial 42 
May  6 15:53:50 server1 named[7332]: running

Figure 4.4: /var/log/messages – BIND DNS logs.

Once you have started the BIND DNS server you can use a variety of tools to check your setup. In this article we will be using the dig command which is an advanced DNS lookup tool. The first command we will issue is dig @localhost example.com this command will query the local DNS server and see what records are available as shown in Figure 4.5.

server1:~ # dig @localhost example.com 

; <<>> DiG 9.3.4 <<>> @localhost example.com 
; (2 servers found) 
;; global options:  printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47721 
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 

;; QUESTION SECTION: 
;example.com.                   IN      A 

;; ANSWER SECTION: 
example.com.            604800  IN      A       192.168.2.141 

;; AUTHORITY SECTION: 
example.com.            604800  IN      NS      example.com. 

;; Query time: 0 msec 
;; SERVER: 127.0.0.1#53(127.0.0.1) 
;; WHEN: Wed May  7 09:53:36 2008 
;; MSG SIZE  rcvd: 59

Figure 4.5: Querying the local DNS server for example.com.

As you can see in Figure 4.5 the A (Address) record returns the IP address 192.168.2.141, if you didn’t get an A record returned then there is a problem with your zone file. The most common problem with zone files is the serial number not being incremented after it has been modified and the missing period (.) after the domain name e.g. “example.com” in a zone file this is incorrect and should be “example.com.” – notice the period.

Once you have queried the DNS server for your FQDN and it returned the A record successfully you can try a reverse lookup e.g. Translate 192.168.2.141 to its FQDN. Figure 4.6 shows the command used to perform a reverse lookup.

server1:~ # dig @localhost -x 192.168.2.141 

; <<>> DiG 9.3.4 <<>> @localhost -x 192.168.2.141 
; (2 servers found) 
;; global options:  printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36123 
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 

;; QUESTION SECTION: 
;141.2.168.192.in-addr.arpa.    IN      PTR 

;; ANSWER SECTION: 
141.2.168.192.in-addr.arpa. 604800 IN   PTR     example.com. 

;; AUTHORITY SECTION: 
2.168.192.in-addr.arpa. 604800  IN      NS      example.com. 

;; ADDITIONAL SECTION: 
example.com.            604800  IN      A       192.168.2.141 

;; Query time: 0 msec 
;; SERVER: 127.0.0.1#53(127.0.0.1) 
;; WHEN: Wed May  7 10:05:30 2008 
;; MSG SIZE  rcvd: 99

Figure 4.6: Reverse lookup.

As you can see in Figure 4.6 the reverse lookup was successful since the FQDN was returned successfully, if you did not receive a FQDN then there is an error with your reverse lookup file, you may want to check you are not missing any periods after the FQDN and that your serial number has been incremented.

Master Server

In this section of the article we need to make a modification to the example.com.zone file so that the slave server has the appropriate permissions to download the zone file. The file that needs to be edited is the named.conf.include file. This file needs to have the allow-transfer directive as shown in Figure 5.

zone "example.com" in { 
        type master; 
        file "master/example.com.zone"; 
        allow-transfer { 192.168.2.135; }; 
};

Figure 5: Allowing zone transfers.

Once you have added the allow-transfer directive which should have the IP address of the slave DNS server you can restart the BIND DNS server as shown in Figure 5.1.

server1:~ # service named restart
Shutting down name server BIND                                        done 
Starting name server BIND                                             done

Figure 5.1: Restarting the BIND DNS server.

Slave Server

Once you have setup the master server you will need to install the BIND DNS server and also create the named.conf.include file which needs to be located within the /etc directory as shown in Figure 2.1. Once you have created named.conf.include you will need to make one zone definition as shown in Figure 6.

zone "example.com" in { 
        type slave; 
        file "slave/example.com.zone"; 
        masters { 192.168.2.141; }; 
};

Figure 6: Slave definition.

As you can see the slave definition is very similar to the zone definition stored on the master server. The only difference is ‘type’ is now set to slave and there is a new directive called: “masters” which lists the IP addresses of the master servers. In our article we only have one master server which has the IP address of 192.168.2.141.

Once you are happy with your zone definition you can start the slave server using the service command as shown in Figure 6.1.

linux-uy85:~ # service named start 
Starting name server BIND                                             done

Figure 6.1: Starting the slave server.

Once the slave server has been started you can check the /var/lib/named/slave directory and you should notice a new file called “example.com.zone” which has been transfered from the master server. You can also view the /var/log/messages file which will show you information about the zone transfer as shown in Figure 6.2.

May  7 14:22:11 linux-uy85 named[8946]: running 
May  7 14:22:11 linux-uy85 named[8946]: zone example.com/IN: Transfer started. 
May  7 14:22:11 linux-uy85 named[8946]: transfer of 'example.com/IN' from 192.168.2.141#53: connected using 192.168.2.135#20232 
May  7 14:22:11 linux-uy85 named[8946]: zone example.com/IN: transferred serial 605200803 
May  7 14:22:11 linux-uy85 named[8946]: transfer of 'example.com/IN' from 192.168.2.141#53: end of transfer

Figure 6.2: /var/log/messages DNS zone transfer logs.

Final Thoughts

In this article we covered setting up and configuring two different types of nameservers, hopefully you should now have a fully functioning DNS server. I would recommend that you visit the ISC website [1] which provides more documentation relating to BIND DNS server and administrative tips.

Reference

[1] http://www.isc.org/index.pl?/sw/bind/index.php

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags:
Categories: Enterprise Linux, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

Comment

RSS