Contact for queries :

Login

  UpComing Live WebEx Workshop Series

Master DNS Server Configuration in Linux

The Configuration mentioned in this post is part of the post “DNS Server Configuration in Linux

A master server is the basis for the DNS infrastructure. It provides a place to define all DNS records and extend them to secondary servers that can help with load balancing and redundancy. For this master server configuration, you need to create a new /etc/named.conf file. You can use the sample /etc/named.conf file to get started. Here is what the named.conf looks like:

/* Global options for the BIND Server */
options
{
directory “/var/named”; // the default
dump-file “data/cache_dump.db”;
statistics-file “data/named_stats.txt”;
memstatistics-file “data/named_mem_stats.txt”;
};
/* Logging options so you know where your logs are going */
logging
{
channel default_debug {
file “data/named.run”;
severity dynamic;
};
};
/* Our sample domain is example.com defined here */
zone “example.com” {
type master;
file “example.com.zone”;
allow-update { none; };
};
/* This is a reverse lookup for our subnet 172.168.1.0/24 */
zone “1.168.172.in-addr.arpa” {
type master;
file “example.com.revzone”;
allow-update { none; };
};
/* File containing root hints (points directly to root DNS servers) */
zone “.” IN {
type hint;
file “named.ca”;
};
/* The zone file for our localhost (good for troubleshooting) */
zone “localhost.” IN {
type master;
file “named.localhost”;
allow-update { none; };
};
/* The reverse lookup zone for our localhost (good for troubleshooting) */
zone “0.0.127.in-addr.arpa.” IN {
type master;
file “named.loopback”;
allow-update { none; };
};

In the sample template here, the zone files are kept in /var/named, but in the real world, these files should actually exist in /var/named/dynamic. If you run into write errors on RHEL6, you should move your zone and reverse zone files into the /var/named/dynamic directory and update your /etc/named.conf file to reflect the changes.

The comments included here should make this config file self-explanatory. Take particular notice of the logging section.

The locations defined here specify where your log files go for BIND (however, some information is also logged to /var/log/messages).

This information is extremely helpful for troubleshooting should the DNS server not work properly. You can change the logging options for more or less information, but it is set up here to initially include enough information for someone to be able to know exactly what is going on.

Now that you have an /etc/named.conf file, you need to create the zone and reverse zone files.

In the /var/named directory, you can set up the following example.com.zone file:

# nano example.com.zone
;
; Zone file for example.com
;
$TTL 86400
@ IN SOA rhel01.example.com. root.example.com. (
2010120710 ; Serial
1d ; refresh
2h ; retry
4w ; expire
1h ) ; min cache
@ IN NS rhel01.example.com.
@ IN A 172.168.1.1
;
; Network Hosts
;
rhel01 IN A 172.168.1.1
rhel02 IN A 172.168.1.2
client01 IN A 172.168.1.10
client02 IN A 172.168.1.20

There are a few issues to make note of here. First, notice that when defining the domain, you put a dot (.) at the end of each FQDN. The root.example.com is the email address of the administrator for the DNS server, which is defined here without an at sign (@).

In the middle of the file, you create two entries for this server, making it the primary nameserver for this domain. Now if a client were to ping the domain name or the server’s hostname (RHEL01), it would respond because it is the primary nameserver. The last few lines define the clients and their IP addresses (notice that these hostnames are not FQDNs).

Let’s now look at the reverse zone file that will allow the DNS server to map IP addresses to hostnames. Again, you can work with the sample provided here:

# nano /var/named/example.com.revzone
;
; Reverse Zone file for example.com
;
$TTL 86400
@ IN SOA rhel01.example.com. root.example.com. (
2010120710 ; Serial
1d ; refresh
2h ; retry
4w ; expire
1h ) ; min cache
@ IN NS rhel01.example.com.
;
; Network Hosts
;
1 IN PTR rhel01.example.com.
2 IN PTR rhel02.example.com.
10 IN PTR client01.example.com.
20 IN PTR client02.example.com.

This file looks almost the same as the forward zone except that instead of A records there are PTR records. The number you see for each client is actually the number in the fourth octet of the IP address (2 correlates to 172.168.1.2). After each PTR definition, you specify the FQDN.

At this point, you still need three files. Two are for the localhost zone and one is the root hints file. On RHEL6, these files are all provided for you in the /var/named directory by default, making the  configuration process much easier.

Everything is now in place for you to begin using your DNS server. Before starting the service, however, make sure that the config files don’t have any syntax errors.

Step 1. You can use the configtest option of the named command to accomplish this:

# service named configtest
zone localhost/IN: loaded serial 42
zone 0.0.127.in-addr.arpa/IN: loaded serial 2010120710
zone example.com/IN: loaded serial 2010120711
zone 1.168.172.in-addr.arpa/IN: loaded serial 2010120710

Step 2. Because no errors are displayed, you can start the service:

# service named start
Starting named: [ OK ]

Real World Information : Don’t forget that to allow zone transfers or zone files to be written, you need to
change the value of the named_write_master_zones Boolean. At this point, you should have a fully functional master DNS server.

Although you aren’t required to know how to set up a master DNS server for the Red Hat exams, this task is commonly performed in the real world. The master DNS server is only the first of four, so let’s move on to the second type: a slave DNS server.

November 16, 2015

1 responses on "Master DNS Server Configuration in Linux"

Leave a Message

Your email address will not be published. Required fields are marked *

About iGURKUL

IGURKUL I.T. Training Hub offering various Career Certification courses in Computer Networking, Unix, Linux, Cloud Computing and DevOps Technologies. With its rich experience in IT training service sector, iGURKUL has been able to set Industry best practices in IT Training for the past five years.

In Past five years, more than 5000 professionals have been trained by iGURKUL for System administration, Cloud Computing and DevOps Skill set through our Online Training portal www.unixadminschool.com. And , each day , more than 10000 working professionals from all over the globe visiting our knowledge base www.unixadminschool.com/blog for the best practices and Knowledge learning.

top
copyright protected - 2011 © igurkul I.T. solutions. All rights reserved.