Hack and / - Your Own Personal Server: DNS

 in
Why let registrars have all the fun? Learn how to set up your own DNS server completely under your own control.

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.

A Short Primer on 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: 76.74.252.198

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 76.75.252.198. 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.

Your Own DNS Server

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.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

huh?

jonny rocket's picture

yawn...

A good high level explanation.

pradeep.aradhya's picture

A good high level explanation.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState