How to set up a home DNS server
by Shannon Hughes
Source: http://www.redhat.com/magazine/025nov06/features/dns/
Domain Name System
The Domain Name System (DNS) is the crucial glue that keeps computer networks in harmony by
converting human-friendly hostnames to the numerical IP addresses computers require to
communicate with each other. DNS is one of the largest and most important distributed databases the
world depends on by serving billions of DNS requests daily for public IP addresses. Most public DNS
servers today are run by larger ISPs and commercial companies but private DNS servers can also be
useful for private home networks. This article will explore some advantages of setting up various types
of DNS servers in the home network.
Why set up a private DNS server?
This question is valid and the answer may vary depending on your home network environment.
Maintaining a host file on each client with IP/hostname mappings in a home network that contains a
router and a few machines may be sufficient for most users. If your network contains more than a few
machines, then adding a private DNS server may be more attractive and worth the setup effort. Some
advantages may include:
Maintenance: keeping track of the host file for every client in your network can be tedious. In fact, it may not
even be feasible for roaming DHCP laptops or your occasional LAN party guests. Maintaining host
information in one central area and allowing DNS to manage host names is more efficient.
Cache performance: DNS servers can cache DNS information, allowing your clients to acquire DNS
information internally without the need to access public nameservers. This performance improvement can add
up for tasks such as web browsing.
Prototyping: A private internal DNS server is an excellent first step to eventually setting up a public
accessible DNS server to access a web server or other services hosted on your internal network. Learning
from mistakes on an internal network can help prevent duplicate errors on a public DNS server that could
result in loss of service for external users. Note: Some ISPs require customers to have a static IP or business
subscription when hosting services in a home network environment.
Cool factor: Ok, I may be stretching it, but the "cool" factor did have some influence when I set up my first
home network DNS server. Creating an internal domain that reflects an individual's personality without
paying a domain registrar and issuing hostnames to your clients is cool. The cool factor doubles when your
customized hostname glows from your friend's laptop screen.
Let's start out simply by setting up a caching-only nameserver to handle client DNS requests. A
caching-only nameserver won't allow references to internal clients by hostname, but it does allow
clients to take advantage of frequently requested domains that are cached.
Caching nameserver
Fortunately, setting up a caching nameserver is easy using RHEL (Red Hat Enterprise Linux) or
Fedora RPMs. The following RPMs need to be installed on the machine acting as the nameserver
(use rpm -q to determine if these packages are installed):
bind (includes DNS server, named)
bind-utils (utilities for querying DNS servers about host information)
bind-libs (libraries used by the bind server and utils package)
bind-chroot (tree of files which can be used as a chroot jail for bind)
caching-nameserver (config files for a simple caching nameserver)
A caching nameserver forwards queries to an upstream nameserver and caches the results. Open the
file /var/named/chroot/etc/named.conf and add the following lines to the global options section:
forwarders { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; }; #IP of upstream ISP nameserver(s)
forward only; #rely completely on our upstream nameservers
The block above will cause the caching name server to forward DNS requests it can't resolve to your
ISP nameserver. Save the named.conf file and then assign 644 permissions:
chmod 644 named.conf
Check the syntax using the named-checkconf utility provided by the bind RPM:
named-checkconf named.conf
Correct any syntax errors (watch those semicolons) named-checkconf reports. Monitoring
the /var/log/messages file may also be helpful in debugging any errors.
We now need to set the local resolver to point to itself for DNS resolution. Modify the/etc/resolv.conf file
to the following:
nameserver 127.0.0.1
If you are running a DHCP server on your router make sure your /etc/resolv.conf file does not get
overwritten whenever your DHCP lease is renewed. To prevent this from happening,
modify /etc/sysconfig/network-scripts/ifcfg-eth0 (replace eth0 with your network interface if different) and
make sure the following settings are set:
BOOTPROTO=dhcp
PEERDNS=no
TYPE=Ethernet
Go ahead and start the nameserver as root and configure to start in runlevels 2-5:
service named start
chkconfig named on
Testing
The bind-utils RPM contains tools we can use to test our caching nameserver. Test your nameserver
using host or dig and querying redhat.com:
dig redhat.com
;; Query time: 42 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
From the above dig query you can see it took 42 msec to receive the DNS request. Now test out the
caching ability of your nameserver by running dig again on the redhat.com domain:
dig redhat.com
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
We dropped from 42 msec to 1 msec after the previous DNS query was cached. Caching is working!
Let's now put the cache to work by configuring the clients to use the new caching nameserver.
Client Configuration
For Linux and Windows clients you may have a couple of options for your resolver configuration
depending on your network environment:
1. If you have a router and your client's IP address is assigned via DHCP from the router, then you can use the
router to assign the primary nameserver during the DHCP lease requested from the client. Log in to your router
and make sure your primary nameserver points to your caching nameserver IP address in the router DHCP
settings.
2. For Linux clients, you can set up the resolver in the same procedure as the nameserver by modifying
the /etc/resolv.conf file. For Windows clients you will need to set the nameserver IP address in the Control
Panel -> Network Connections -> TCP/IP -> Properties -> Use the DNS Server Address option. NOTE: The
Windows DNS server option may vary depending on your version.
Test your new client configuration(s) using dig. You can use the nslookup command for Windows
clients. Your DNS requests should have similar response times as we saw earlier when testing the
nameserver directly.
NOTE: If you are running a firewall on the nameserver system, make sure clients have access to port
53. An example iptables rule for the 192.168.15.0/24 subnet would be:
iptables -A INPUT -s 192.168.15.0/24 -p udp --dport 53 -j ACCEPT
service iptables save
Summary
Your new caching nameserver offers a performance improvement with a minimal amount of set up
effort. Clients can now ask the caching nameserver for DNS information, and it only needs to ask the
upstream ISP nameserver for cache misses. In the next issue we will setup a master nameserver that
is responsible for the authoritative information for our internal client hostnames. An authoritative
nameserver also caches by default but additionally allows managing both static and DHCP clients
using personalized hostnames set up in zone files. In the meantime, enjoy your new caching
nameserver and be thinking about a creative domain and hostname theme for your future authoritative
nameserver.
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.
