1. DNS server & Client Objectives Contents
to learn how to setup dns servers
Contents
An Introduction to DNS
How To Download and Install The BIND Packages
How To Get BIND Started
The /etc/resolv.conf File
Configuring A Caching Nameserver
Important File Locations
Configuring A Regular Nameserver
Troubleshooting BIND
What Is DNS?
As explained on the introduction to networking concepts chapter, the Domain Name System (DNS) is the way in which a website like is converted to an IP address.
What's a Domain?
Everyone in the world has a first name and a last or "family" name, DNS is similar. Domains can be simply described as the name given to a family of websites. For example the domain linuxhomenetworking.com has a number of children such as and mail.ikea.se.
What Is BIND?
BIND is an acronym for the "Berkeley Internet Name Domain" project which maintains the DNS related software suite that runs under Linux. The most well known program in BIND is "named", the daemon that responds to DNS queries from remote machines.
What's A DNS Client?
A DNS client doesn't store DNS information; it always has to refer to a DNS server to get it. The only DNS configuration file for a DNS client is the /etc/resolv.conf file which defines the IP address of the DNS server it should use. You shouldn't need to configure any other files.
What's An Authoritative DNS Server?
These are the servers that provide the definitive information for your DNS domain such as the names of servers and websites in it.
How DNS Servers Find Out Your Site Information?
There are ~thirteen "root" (super duper) authoritative DNS servers which all DNS servers query first. These servers know all the authoritative DNS servers for all the main domains such as ".com", ".net" etc. These servers keep track of all the sub domains beneath them.
When To Use A DNS Caching Name Server?
Most servers don't ask authoritative servers for DNS directly, they usually ask a caching DNS server to do it on their behalf. The caching DNS servers then store (or cache), the most frequently requested information to reduce the lookup overhead of subsequent queries.
If you want to advertise your website to the rest of the world, then a regular DNS server is what you require. Setting up a caching DNS server is fairly straightforward and will work whether or not your ISP provides you with a static or dynamic Internet IP address.
Once you have set up your caching DNS server you will then have to configure each of your home network PCs to use it as their DNS server. If your home PCs get their IP addresses using DHCP, then you will have to configure your DHCP server to make it aware of the IP address of your new DNS server so that it can advertise it to its PC clients. Off the shelf router/firewall appliances used in most home networks will usually act as both the caching DNS and DHCP server. In this case a separate DNS server is unnecessary.
When To Use A Static DNS Server?
If your ISP provides you with a "fixed" or "static" IP address, and you want to host your own website then a regular authoritative DNS server would be the way to go. A caching DNS name server is only used as a reference, regular name servers are used as the authoritative source of information for your website's domain.
Note: Regular name servers are also caching name servers by default.

2. Download and Install The DNS Package
Download the DNS server
(anser yes on all, you dont need developers if you dont compile)
Install the RPM’s
You can also obtain dhcp sources directly from
# ftp ftp.redhat.com/pub/redhat/linux/9/en/os/i386/RedHat/RPMS …
mget bind*
# rpm –ivh bind i386.rpm …
Most RedHat and Fedora Linux software products are available in the RPM format. Downloading and installing RPMs isn't hard. If you need a refresher, the chapter on RPMs covers how to do this in detail.
When searching for the file, remember that the BIND RPM's filename usually starts with the word "bind" followed by a version number like this:
bind i386.rpm
bind-devel i386.rpm
bind-utils i386.rpm
caching-nameserver noarch.rpm (needed for caching nameserver files)

3. How To Get BIND Started Set named/bind startup at boot:
You can use the chkconfig command to get BIND configured to start at boot:
To start/stop/restart BIND after booting
Without any configuration bind act as cache only
# chkconfig named on
# /etc/init.d/named start
# /etc/init.d/named stop
# /etc/init.d/named restart
Note: Remember to restart the BIND process every time you make a change to the configuration file for the changes to take effect on the running process.
caching-nameserver noarch.rpm caching-nameserver noarch.rpm

4. RedHat 9 Errors When Restarting BIND
Trying to restart bind can give this result:
Brute force restart
You may have to use brute force to get it restarted by using the "pkill" command followed by restarting the named init script.
# /etc/init.d/named restart
Stopping named:
named: already running
# pkill -KILL named
pkill: No such process
pkill: No such process
pkill: No such process
# /etc/init.d/named start
RedHat 9 doesn't shutdown BIND cleanly and will give a "named: already running" error like the one below when you try to restart it.

5. The client /etc/resolv.conf File
Sample resolv.conf file:
The client server's main domain is my-site.com, but it also is a member of domains my-site.net and my-site.org which should be searched for short hand references to other servers.
Two nameservers, and provide DNS name resolution.
Don’t forget /etc/nsswitch.conf and host.conf
hosts: files dns order hosts,bind
The nameserver need loopback as first nameserver:
domain my-site.com
search my-site.com net my-site.net my-site.org
nameserver
nameserver
This file is used by DNS clients (servers not running BIND) to determine both the location of their DNS server and the domains to which they belong. It generally has two columns, the first contains a keyword and the second contains the desired value(s) separated by commas.
Nameserver
IP address of your DNS nameserver. There should be only one entry per "nameserver" keyword. If there is more than one nameserver, you'll need to have multiple "nameserver" lines.
Domain
The local domain name to be used by default. If the server is bigboy.my-site.com, then the entry would just be my-site.com
Search
If you refer to another server just by its name without the domain added on, DNS on your client will append the server name to each domain in this list and do an nslookup on each to get the remote servers' IP address. This is a handy time saving feature to have so that you can refer to servers in the same domain by only their servername without having to specify the domain. The domains in this list must separated by spaces.
nameserver

6. Configuring A Caching Nameserver
In /etc/resolv.conf:
Example old Entry
nameserver
Example New Entry
# nameserver
or:
nameserver
This must be first in the list of nameservers, if there are more!
The RedHat / Fedora default installation of BIND is configured to convert your Linux box into a caching name server. The only file you have to edit is /etc/resolv.conf in which you'll have to comment out the reference to your previous DNS server (most likely your router) with a "#" or make it point to the server itself using the universal localhost IP address of
Remember that resolv.conf is updated by dhcp servers if your PC recieves dynamic IP addresses from somewhere.

7. Configuring A Regular Nameserver
Configuring /etc/resolv.conf
You'll have to make your DNS server refer to itself for all DNS queries by configuring the /etc/resolv.conf file to only reference localhost.
Configuring /etc/named.conf home/port
This is the head
of named.conf
Forward resoulution: Revers resolution:
options {
directory "/var/named";
query-source port 53; };
The main DNS configuration is kept in the /etc/named.conf file which is used to tell BIND where to find the configuration files for each domain you own. There are usually two zone for each domain in this file:
Forward zone file definitions which list files to map domains to IP addresses
Reverse zone file definitions which list files to map IP addresses to domains
Step 1 is to change the caching only DNS configuration files. We begin with the /etc/resolv.conf file.
The attribute options declare where zonefiles sit and also what port the nameserver listens on:
The default directory is /var/named/ and default query-source port is 53 (udp for name resolution and tcp for zone transfers)
Step 2 Directly after the options attributes sit the two cache only nameserver declaration looks like this:
; Loopback resolution
zone " IN-ADDR.ARPA" {
type master;
file "named.local"; };
; ROOT nameservers to resolve other domain nodes
zone "." {
type hint;
file "named.ca";
Step 3 Is to allow or deny nodes in networks to resolve names, default is ”all”
ACL example:
acl trustednets { /24; ; }
ACL usage:
allow-query { trustednets; };
zone ”my-site.com" {
type master; notify no;
allow-query { any; }; file "my-site.zone"; };
zone ” in-addr.arpa" {
type master; notify no; file ” rev"; };

8. Configuring A Regular Nameserver ”extras”
Activate logging
After the ”head” in
/etc/resolv.conf
Here we log only
zone transfers and
mandatory messages:-
Masterzone
Example
Masterzone, that notify 2 slaves:
logging {
category xfer-out {
default_syslog; };
category xfer-in {
category lame-servers {
null;
Step 4 Logging is not nessesary, but it is important to know if master files are transfered to slaves, so called zone transfers. There are several nameserver category’s to log. default_syslog tells to log in syslog and null tells to not log that category at all.
Step 5 Activate zone transfers for your zones if you have slaves.
In example we have two slaves that are notified to poll this nameserver masterzone. Everyone can also query this zone for names/addresses. In /etc/resolv.conf zone declaration:
allow-transfer { server1; server2; }
notify yes;
Will perform zone transfer attempts everytime you plus the serial number inside the zonefile to all servers inside the { }, they are assumed to be setup as slaves.
The revers notify no; will disable automatic zone transfers.
A slavezone is setup with type slave; an example of slaveserver to our master( ):
zone ”my-site.com” {
type slave;
file ”/var/named/my-site.com”;
masters { ; }; };
zone ”my-site.com" {
type master;
file "/var/named/my-site.com";
allow-query { any; };
allow-transfer { ;
; localhost; };
notify yes; };

9. Configuring the Zone Files SOA
In the head of /var/named/my-site.com:
Time to Live Value on first line:
Cache lifetime of this file, allways in top of zonefile!
The SOA (Start Of Authority) Record
my-site.com. is this zonefile served domain
ns.my-site.com. is the nameserver fqdn
root.my-site.com. is the mail address (dns-admin)
The serial number is extremely important. You MUST increment it after editing
the file or else BIND will not apply the changes you made when you restart "named".
$TTL 3D
my-site.com. IN SOA ns.my-site.com. root.my-site.com. (
; incremental serial number (s)
10800 ; slave refresh ratio (s)
3600 ; slave retry interval (s)
; slave retry expires (s)
86400 ) ; cache TTL
Step 6 The first file to setup after: /etc/named.conf is the forward resolving zonefile: /var/named/my-site.com
We begin with the $TTL and SOA record! (SOA record is the same format in the reverse zone file)
In all zone files, you can place a comment at the end of any line by inserting a semi-colon ";" character then typing in the text of your comment. By default, your zone files are located in the directory /var/named.
Each zone file contains a variety of records (eg. SOA, NS, MX, A and CNAME) which govern different areas of BIND. I'll explain of them below and then follow it all up with an example.
Caching DNS servers cache the responses to their queries from authoritative DNS servers. The authoritative servers not only provide the DNS answer but the valid lifetime or time to live (TTL) of the information.
The purpose of a TTL is to reduce the number of DNS queries the authoritative DNS server has to answer. If the TTL is set to three days, which is usually the default, then caching servers will use the original stored response for this length of time before making the query again. The TTL value for the zone is usually the very first entry in the zone file. In the example below, it is set to three days.
The very first record is the Start of Authority (SOA) record which contains general administrative and control information about the domain. Though you would normally think a record would be a single line, the SOA format spans several. It is the most counter-intuitive of them all, the rest of the records are relatively straight forward.
NOTE: Format of zonefiles varies by version of bind, real mess actually!

10. Next in the zonefile is NS & MX RECORD’s
The IN NS name server record’s for the domain
Tells who resolve names for the domain
my-site.com. is the served domain
ns.my-site.com. is the nameserver fqdn for this domain.
The IN MX name server record’s
Tells who handle in the domain
mail.my-site.com. is the primary mailserver
mail2.my-site.com. is the secondary mailserver
; Define the nameservers
my-site.com. IN NS ns.my-site.com. ; master
my-site.com. IN NS ns2.navab.net. ; slave
Step 7 Directly after the SOA record in the forward resolution zonefile we have to declare who is nameservers for this domain and also who handles . Unlike the SOA record, the NS, MX, A and CNAME records each occupy a single line and the records each have a very similar layout.
IN NS ns.my-site.com ;The master dns
IN MX 10 mail.my-site.com ;The master mailserver (10 is priority higher than 20)
Note: If you don't put a "." at the end of a host name in a SOA, NS, A or CNAME record, BIND will automatically tack on the domain name. So an "A" record with "www" will be assumed to refer to This may be OK in most cases, but if you forget to put the "." after the domain in the MX record for my-site.com, BIND will attach the my-site.se at the end, and you will find your mail server only accepting mail for the domain my-site.com.my-site.com. If same priority level in after MX record, round robin will be used.
; Define the mailservers
IN MX mail.my-site.com.
IN MX mail2.my-site.com.

11. Populate zonefile with IN A & CNAME records
The IN A (InterNet Address) record’s for the domain
ns will be extended to ns.my-site.com since we did not end with .
mail will be extended to mail.my-site.com
The CNAME record’s for the domain
ftp will be extended to ftp.my-site.com with mail’s IP
www will be extended to with ns’s IP
; Define the hosts in this zone
ns IN A ; primary nameserver
mail IN A ; pri mailserver
mail2 IN A ; sec mailserver
Zyxel IN A ; zyxel router
Step 8 After defining nameservers and mailservers for our domain forward zonefile, we need to populate the forward zone with hosts to resolv IP addresses for. We simply add all nodes after the last MX entry in /var/named/my-site.com the format is fairly simple, example:
ns.my-site.com. IN A ; will be ns.my-site.com
mail IN A ; will be mail.my-site.com
mail2 IN A
imap.my-site.com. IN A ; Hard coded alias
CNAME ns.my-site.com ; Alias name
Internet community and ISP’s around the world try to agree using CNAME instead of direct IN A entries for hostst with same IP address, because you can see who is canonical name or not in that case, otherwise not.
Also we follow the format in the files that internet community tries to agree on.
Note ! If your nameserver dies by some reason, or administrator misses to sighup/reload after modify entries, nothing will happen directly. It can take several days, up to weeks before the other world starts to make trouble.
Zonetransfers are usally distributed around the world to other nameserver in less than 2 hours.
; alias names
ftp CNAME mail.my-site.com.
student CNAME mail2.my-site.com.
www CNAME ns.my-site.com.
ntp CNAME mail1.my-site.com.

12. The reverse Zone File File has the same SOA format as the forward
Exept the SOA opening statement which is reverse:
The PTR reverse pointer record’s look like:
$ttl 3d
in-addr.arpa. IN SOA ns.my-site.com. root.my-site.com. ( same SOA as on page 9 of 17 )
; nameservers
in-addr.arpa. IN NS ns.my-site.com.
in-addr.arpa. IN PTR mail.my-site.com.
in-addr.arpa. IN PTR mail2.my-site.com.
; normal pointers
in-addr.arpa. IN PTR zyxel.ng-steen.com.
; alias names
ftp.my-site.com IN CNAME mail.my-site.com.
Student.my-site.com. IN CNAME mail2.my-site.com.
IN CNAME ns.my-site.com.
ntp.my-site.com IN CNAME mail2.my-site.com.
Step 9 This file is almost the same as forward file, only remember that everything is ”reverse”, because it is reverse lookup file, asking IP will return fqdn.
You begin with the SOA statement, follow page 9 of 17, only change the domain declaration in front of IN SOA statement, the rest of the SOA is exactly the same as in the forward zonefile.
$TTL 3D
in-addr.arpa. IN SOA ns.my-site.com root.my-site.com ( Page 9 of )
Step 10 Declare who is nameserver for this domain, now in reverse order:
in-addr.arpa. IN NS ns.my-site.com.
Or you can also type:
<tab> IN NS ns.my-site.com.
Step 11 Populate the reverse zonefile with nodes, now we have to tell IN PTR (InterNet reverse PoinTeR):
in-addr.arpa. IN PTR ns.my-site.com.
in-addr.arpa. IN PTR mail.my-site.com.
in-addr.arpa. IN PTR mail2.my-site.com.
. . .

13. Loopback reverse lookup
Needed for named loopback reverse lookups
/var/named/named.local
$TTL 3D
@ IN SOA ns.my-site.com. root.my-site.com. (
; Serial
; Refresh
; Retry
; Expire
86400 ) ; Minimum
IN NS ns.my-site.com.
IN PTR localhost.
Step 12 This file is needed for reverse loopback! It should already be there from caching-nameserver only rpm.
You only need to enter the nameserver and address:
ns.my-site.se. root.my-site.com.
And also you need to enter the NS record:
IN NS ns.my-site.com.

14. Root servers file (cache root servers)
/var/named/named.ca
. Means all network
Timeout set to max
; formerly NS.INTERNIC.NET
IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET A
; formerly NS1.ISI.EDU
NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET A
Step 13 This is the top level domain nameservers. This file follows installation of caching-nameserver rpm. If not you can download it from internet. If you do not have any external network connections, you enter your root nameservers here.
This file is used to resolve other nodes in other domains that your DNS does not have in its zonefiles.

15. Internal/External queries
Different name lookups for internal and external networks: /etc/named.conf
view internal
view "internal" { // What the internal network will see
add your zones }
view external
view "external" { // What the public network will see
Step 14 In the more secure networks you might want to have different dns answers for internal and external networks. If you do, you can declare internal and external views.
Normally you do only need this if nameserver is both public and private, othervise you use ACL to form groups that can query and not.
Here's a summary of how it's done:
Place your zone statements in the /etc/named.conf file in one of two "views" sections. The first section will be called "internal" and will list the zone files to be used by your internal network. The second view called "external" will list the zone files to used for Internet users.
For example; you could have a reference to a zone file called my-site.com for lookups related to the X network which Internet users would see. This /etc/named.conf entry would be inserted in the "external" section. You could also have a file called my-site-home.com for lookups by home users on the network. This entry would be inserted in the "internal" section. The creation of the my-site-home.zone file is fairly easy. Just copy it form the my-site.zone file and replace all references to X with references to X
You must also tell the DNS server which addresses you feel are "internal" and "external". This is done by first defining access control lists (ACLs) and then referring to these lists within each view section with the match-clients statement. There are some built-in ACLs:
+        "localhost" which refers to the DNS server itself;
+        "localnets" which refers to all the networks to which the DNS server is directly connected;
+        "any"  which is self explanatory.
Note: You must place your "localhost", " in-addr.arpa" and "." zone statements in the "internal" views section. Remember to increment your serial numbers!

16. Now it’s time to test your configurations
Restart your nameserver
# killall named ; service named start
Check your /var/log/messages file for errors, and correct!
Check forward resolution
# nslookup ns.my-site.se
Name: ns.my-site.se
Address:
Check reverse resolution
# nslookup
in-addr.arpa name = ns.my-site.se.
Step 15 Test your nameserver! Test both forward and reverse lookup for your domains. In real life also test resolving of external networks.
Host is another tool for check name resolution:
host mail.my-site.se ns.my-site.se
Dig is yet another tool for the same thing:
dig my-site.se SOA
dig ns.my-site.se my-site.se SOA
Note: Check not only one host in your network, check them all, errors can be anywere!
The /var/log/messages file is helpful finding errors when you start and stop nameserver, also
For zone file transfers it is helpful. Check man named to see how you can start with verbose dump levels to see queries details, dont forget to stop verbose debugging after.

17. Summary DNS server is used to resolve name and IP
Configuration sit in /etc/named.conf
Zonefiles are in /var/named/
Zone transfter from master to slaves
Cache only nameserver is default setting
You have two files for each zone
Hosts can share same IP with CNAME
Stop dns server with /etc/init.d/named stop
Reload dns server with /etc/init.d/named restart
ACL and view can policy quieries
It takes time for names to update globaly
DNS server has as first entry in /etc/resolv.conf