Hack and / - Your Own Personal Server: DNS
In this day and age, it's simple and popular to have someone else change your oil, grow your vegetables, remodel your house and host your services. However, I'd argue that it's far more rewarding, educational and not very difficult to manage these things yourself. This column is the second in a series about how to manage your own services on your own server. In the first column, I discussed how to make sure your home network is ready to host your own services. In this column, I start to get into the meat of the topic and discuss the first service you can (and should) set up at home: DNS.
DNS (Domain Name System) is a system you use every day and one on which the Internet heavily depends. Every server (including your own) that has a presence on the Internet should have a public IP address. Since last month's column, you should have your home network set up for your server and have at least one public IP (hopefully static) you can use. It's true that all you really need to host many services on the Internet is an IP address; however, in practice, there are only so many IP addresses (like phone numbers) that the average person is going to commit to memory. As IPv6 becomes commonplace, this will be even more true. DNS allows you to register a domain name and associate individual host names (like www.example.com and mail.example.com) to IP addresses.
For instance, how many of you (besides you, Katherine) have www.linuxjournal.com's IP address memorized? If you did want to know the IP address, all you would need to do is perform a simple nslookup command:
$ nslookup www.linuxjournal.com Server: 192.168.0.1 Address: 192.168.0.1#53 Non-authoritative answer: Name: www.linuxjournal.com Address: 18.104.22.168
In this example, the first bit of output tells me that I'm getting this answer from a DNS server at 192.168.0.1 (my own personal DNS server) and that the IP address for www.linuxjournal.com is currently 22.214.171.124. There isn't enough space in this column to describe everything that happened to allow me to get that IP address, but essentially, my DNS server asked other DNS servers on the Internet for this IP address and was subsequently redirected to more and more DNS servers until it finally found the one that knew the answer. If you are interested in more detail on how this works, books like DNS and BIND do a good job of explaining it, or from the command line, you could run dig www.linuxjournal.com +trace.
DNS seems like a complicated service, yet it's relatively simple to set up a DNS server of your own. Now, there are a number of different DNS server software from which to choose that are easier to configure or that have fancy database back ends, but for this article, I'm going to choose the old standby, BIND. Although it's not as simple as other DNS servers, it isn't so bad, once you get the hang of it.
BIND should be packaged for most major distributions; however, there are slight differences in how each distribution packages BIND. For instance, under Red Hat, you install the bind package, but under Debian-based systems (like Ubuntu), you install bind9. Red Hat stores its core BIND configuration file at /etc/named.conf and all its zone files (files that contain name→IP address mappings for a domain, such as example.org, a subdomain, such as ny.example.org, or possibly both) under /var/named, while Debian-based systems put named.conf and any zone files under the /etc/bind/ directory. Even the init script is different on both systems: Red Hat uses /etc/init.d/named, and Debian-based systems use /etc/init.d/bind9. Once you get past the differences, however, the syntax inside the files should be similar. Just to simplify things, I'm going to base the rest of this article off a standard Ubuntu 10.04 LTS server, so we have some sort of baseline. If you use a different distribution, however, it shouldn't be too difficult to adapt these instructions to the different file paths.
Once BIND is installed on the system, the package should create a basic named.conf file and all of the base directories. In the case of this sample Ubuntu system, the default named.conf actually will be set up to act as a caching name server. So, out of the box you should be able to point to this server with other hosts on your network, and it will be able to resolve other domains on the Internet just like with your ISP's DNS server. In this case, though, we want to create a DNS master.
Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
- New Products
- Users, Permissions and Multitenant Sites
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- High-Availability Storage with HA-LVM
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Solving ODEs on Linux
- Not So Dynamic Updates
- Non-Linux FOSS: MenuMeters