redhat.com | How to set up a home DNS server, part II http://www.redhat.

com/magazine/026dec06/features/dns/

December 12, 2006

Rate this page (javascript: openwindow()) (http://del.icio.us/post) del.icio.us (http://del.icio.us/post) (http://digg.com/submit) Digg

(http://digg.com/submit) (javascript:location.href='http://slashdot.org/bookmark.pl?url='+encodeURIComponent(location.href)+'&

title='+encodeURIComponent(document.title)) slashdot (javascript:location.href='http://slashdot.org

/bookmark.pl?url='+encodeURIComponent(location.href)+'&title='+encodeURIComponent(document.title))

(javascript:location.href='http://www.stumbleupon.com/submit?url='+encodeURIComponent(location.href)+'&

title='+encodeURIComponent(document.title)) StumbleUpon (javascript:location.href='http://www.stumbleupon.com

/submit?url='+encodeURIComponent(location.href)+'&title='+encodeURIComponent(document.title))

If you missed the first part (/magazine/025nov06/features/dns/), go get caught up. Then join us for
more DNS and hostname goodness. Last time, we got you up and running. This time, see how you
can manage all the hostnames in your domain with just a few DNS tricks.

HOW TO SET UP A HOME DNS SERVER, PART II

by Shannon Hughes

Welcome back
In the first part of this series on the Domain Name System (DNS), we set up a caching nameserver that
allowed our clients to take advantage of faster network operations by caching frequently requested DNS
queries. In this article, we will extend our caching nameserver to a master nameserver that is responsible
for managing the authoritative information for our internal client hostnames.
Overview
As with our caching-only nameserver, we will see that BIND RPMS packaged by Red Hat® Enterprise
Linux® and Fedora ease the process of configuring our master nameserver. Adding authoritative
responsibility to the caching-only nameserver only requires us to add two more files and modify the
existing named.conf file. For the purpose of this article we will assume the following:

The BIND 9.x RPMS discussed in Part 1 are installed on the machine that will serve as a
nameserver.
Our internal network is in the 192.168.15.0/24 subnet. You will need to substitute your subnet if
different.
The master nameserver will only allow DNS queries from internal clients in the 192.168.15.0/24
subnet.
The master nameserver will continue to forward any DNS requests it can't answer to your
upstream ISP nameserver(s).
We will use the domain hughes.lan as our internal domain name.

You might notice that we selected a mock top-level domain (sometimes referred as a TLD) named lan.
Our internal domain name can be as creative as we wish since the domain is only known inside our
home network. The naming convention for a public nameserver is not as relaxed, since we would need
to follow certain rules that would allow our nameserver to respond to other nameservers requesting

1 of 6 27/01/2011 13:04
redhat.com | How to set up a home DNS server, part II http://www.redhat.com/magazine/026dec06/features/dns/

host information from around the world.

Zones
Nameservers store information about a domain namespace in files called zone data files. A zone data file
contains all the resource records that describe the domain represented in the zone. The resource records
further describe all the hosts in the zone. We will need to modify our existing named.conf to reference
two zone files for our domain name:

Forward zone definitions that map hostnames to IP addresses.

Reverse zone definitions that map IP addresses to hostnames.

Open /var/named/chroot/etc/named.conf and add the following forward and reverse zone file
directives:

# Forward Zone for hughes.lan domain

zone "hughes.lan" IN {
type master;
file "hughes.lan.zone";
};

# Reverse Zone for hughes.lan domain

zone "15.168.192.in-addr.arpa" IN {
type master;
file "192.168.15.zone";
};

Both the forward and reverse zones contain the type master indicating that our nameserver is the
master or primary nameserver for the hughes.lan domain. The file keyword indicates which zone file
contains the resource records for the corresponding zone. Note that the reverse zone contains a special
domain named in-addr-arpa. DNS uses this special domain to support IP to hostname mappings.
Reverse lookups are backwards since the name is read from the leaf to the root (imagine a domain name
as a tree structure) so the resultant domain name has the topmost element at the right-hand side. For a
home network the reverse lookup zones can be considered optional but we will include them for
completeness.
Included with the BIND RPMs is a root zone nameservers use when a query is unresolvable by any
other configured zones. The root zone directive is named ".", has a type of hint and references a file
named named.ca that contains a list of 13 root name servers located around the world. We will not
directly use the root servers since we are forwarding any unresolvable queries to our ISP nameservers.

We need to modify the named.conf global options to allow our internal clients to query the
nameserver. Modify the existing global options block to the following:

acl hughes-lan { 192.168.15.0/24; 127.0/8; };

options {
directory "/var/named";
allow-query { hughes-lan; };
forwarders { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; }; # ISP primary/secondary
forward-only; # Rely completely on ISP for cache misses
};

The acl statement above sets up a range of IP addresses we can reference throughout the named.conf

2 of 6 27/01/2011 13:04
redhat.com | How to set up a home DNS server, part II http://www.redhat.com/magazine/026dec06/features/dns/

file. The allow-query specifies IP addresses of hosts that can query our nameserver. The forwarders
statement tells our nameserver to forward any unresolvable queries to our upstream nameservers. The
forward-only statement restricts our nameserver to only rely on our ISP nameservers and not contact
other nameservers to find information that our ISP can not provide. It's very rare for a primary and
secondary ISP nameserver to be down at the same time but you can comment forward-only if you
want your nameserver to try the root nameservers when the upstream ISP nameservers cannot resolve a
hostname.
Zone files
We are now ready to start defining our hostname mappings in the zone files we referenced in the
named.conf configuration. Zone files need to be placed in the /var/named/chroot/var/named
directory, have 644 permissions with an owner and group of named:

cd /var/named/chroot/var/named
touch hughes.lan.zone
chown named:named hughes.lan.zone
chmod 644 hughes.lan.zone

Let's take a look at an example zone file for the hughes.lan forward zone and then dive into the various
parts:

$TTL 1D

hughes.lan. IN SOA velma.hughes.lan. foo.bar.tld. (

200612060 ; serial
2H ; refresh slaves
5M ; retry
1W ; expire
1M ; Negative TTL
)

@ IN NS velma.hughes.lan.

velma.hughes.lan. IN A 192.168.15.10 ; RHEL server

fred.hughes.lan. IN A 192.168.15.1 ; router
scooby.hughes.lan. IN A 192.168.15.2 ; upstairs WAP
shaggy.hughes.lan. IN A 192.168.15.3 ; downstairs WAP
scooby-dum.hughes.lan. IN A 192.168.15.4 ; Fedora desktop
daphne.hughes.lan. IN A 192.168.15.5 ; network printer
mysterymachine IN A 192.168.15.6 ; mail server
scrappy IN A 192.168.15.7 ; Windows box
; aliases
www IN CNAME velma.hughes.lan. ; WWW server
virtual IN CNAME velma ; virtual WWW tests
mail IN CNAME mysterymachine ; sendmail host

; DHCP Clients
dhcp01.hughes.lan. IN A 192.168.15.100
dhcp02.hughes.lan. IN A 192.168.15.101
dhcp03.hughes.lan. IN A 192.168.15.102
dhcp04.hughes.lan. IN A 192.168.15.103
dhcp05.hughes.lan. IN A 192.168.15.104

@ IN MX 10 mail.hughes.lan.

3 of 6 27/01/2011 13:04
redhat.com | How to set up a home DNS server, part II http://www.redhat.com/magazine/026dec06/features/dns/

The very first line in the hughes.lan.zone contains the TTL (Time To Live) value and is set to one day.
TTL is used by nameservers to know how long to cache nameserver responses. This value would have
more meaning if our nameserver was public and had other external nameservers depending on our
domain information. Notice the 'D' in the TTL value stands for Day. Bind also uses 'W' for weeks, 'H' for
hours, and 'M' for minutes.
The first resource record is the SOA (Start Of Authority) Record which indicates that this nameserver is
the best authoritative resource for the hughes.lan domain. The IN stands for Internet Class and is
optional. The first hostname after the SOA is the name of our master or primary nameserver. The
second name, "foo.bar.tld.", is the email address for the person in charge of this zone. Notice the '@' is
replaced with a '.' and also ends with a '.'. The third value is the serial number that indicates the
current revision, typically in the YYYYMMDD format with a single digit at the end indicating the
revision number for that day. The fourth, fifth, sixth, and seventh values can be ignored for the
purposes of this article.

The NS record lists each authoritative nameserver for the current zone. Notice the first '@' character in
this line. The '@' character is a short-hand way to reference the domain, hughes.lan, that was
referenced in the named.conf configuration file for this zone.

The next block of A records contains our hostname to address mappings. The CNAME records act as
aliases to previously defined A records. Notice how fully qualified domains end with a '.'. If the '.' is
omitted then the domain, hughes.lan, is appended to the hostname. In our example the hostname,
scrappy, will become scrappy.hughes.lan

If you want to reference an internal mail server, then add a MX record that specifies a mail exchanger.
The MX value "10" in our example indicates the preference value (number between 0 and 65535) for
this mail exchanger's priority. Clients try the highest priorty exchanger first.

The reverse zone file, 192.168.15.zone, is similar to our forward zone but contains PTR records
instead of A records:

4 of 6 27/01/2011 13:04
redhat.com | How to set up a home DNS server, part II http://www.redhat.com/magazine/026dec06/features/dns/

$TTL 1D

@ IN SOA velma.hughes.lan. foo.bar.tld. (

200612060 ; serial
2H ; refresh slaves
5M ; retry
1W ; expire
1M ; Negative TTL
)

IN NS velma.hughes.lan.
10 IN PTR velma.hughes.lan.
1 IN PTR fred.hughes.lan.
2 IN PTR scooby.hughes.lan.
3 IN PTR shaggy.hughes.lan.
4 IN PTR scooby-dum.hughes.lan.
5 IN PTR daphne.hughes.lan.
6 IN PTR mysterymachine.hughes.lan.
7 IN PTR scrappy.hughes.lan.

100 IN PTR dhcp01.hughes.lan.

101 IN PTR dhcp02.hughes.lan.
102 IN PTR dhcp03.hughes.lan.
103 IN PTR dhcp04.hughes.lan.
104 IN PTR dhcp05.hughes.lan.

Testing
Save your zone files, make sure you have the correct permissions and check the syntax using named-
checkzone:

named-checkzone hughes.lan hughes.lan.zone

named-checkzone 15.168.192.in-addr.arpa 192.168.15.zone

Correct any syntax errors reported by named-checkzone.

Restart the nameserver:

service named restart

Browse through the tail of the /var/log/messages file and confirm the domain loaded successfully.
Make the following DNS queries (substituting your domain):
dig scooby.hughes.lan
dig -x 192.168.15.2

Your output should be similar to the following:

5 of 6 27/01/2011 13:04
redhat.com | How to set up a home DNS server, part II http://www.redhat.com/magazine/026dec06/features/dns/

.
.
.

;; QUESTION SECTION:
;scooby.hughes.lan. IN A

;; ANSWER SECTION:
scooby.hughes.lan. 86400 IN A 192.168.15.2

;; AUTHORITY SECTION:
hughes.lan. 86400 IN NS velma.hughes.lan.

;; ADDITIONAL SECTION:
velma.hughes.lan. 86400 IN A 192.168.15.10
.
.
.

Continue to test each host you added to the zone file and then enjoy your new master nameserver.
Conclusion
The goal of this series of DNS articles was to pick the high-level features DNS can offer to improve the
efficiency and management of the home network. In addition to the performance improvement we saw
with the caching nameserver, the master nameserver helps manage both static and dynamic clients using
human-friendly hostnames instead of IP addresses. For readers interested in learning more about DNS
or expanding the nameservers discussed in this series, checkout the following resources:

BIND user documenation located in /usr/share/doc/bind-9.x.x

DNS and BIND (5th Edition) (http://www.amazon.com/gp/product/0596100574?ie=UTF8&
tag=wwwredhatcom-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0596100574)

About the author

Shannon Hughes is a Red Hat Network (RHN) engineer who enjoys using open source software to solve the most demanding software projects. When
he is not cranking out code, tweaking servers, or coming up with new RHN projects, you can find him trying to squeeze in yet another plant in the
yard/garden with his wife, watching Scooby Doo reruns with his two kids and dog, or incorporating the latest open source projects for his church
(http://www.fv baptist.org).

Copyright © 2010 Red Hat, Inc. All rights reserved.

: : : : :

6 of 6 27/01/2011 13:04