This article talks about setting up your own public name server, allowing you to have complete control over DNS for your domains. It will cover the steps I went through to achieve this. Where I encountered difficulty will have greater amounts of detail. The actual installation of a name server is covered in my article Installing PowerDNS.
I would recommend first working with DNS internally for non-critical machines, in order to get the hang of DNS. Once you feel comfortable maintaining DNS privately, move onto your public servers. Ensure you can switch back to your old DNS system as a backup — in case something goes wrong. Take it a step at a time.
The one indispensable tool that I use in all aspects of our computing environment is VMware. Being able to separate an operating system from a physical machine allows unprecedented freedom to experiment, make mistakes, and undo those mistakes. When you’re ready to roll out a production server, copy the virtual machine and you’re done without any risks of misconfiguring a new machine in the process.
Step One: Preparation
Create a new DNS server. After banging my head against BIND’s configuration files for years, I tried PowerDNS. I found its simplicity refreshing. If you’d like to try PowerDNS, you may be interested in my notes for setting up PowerDNS.
Use this machine to become familiar with DNS. On my workstation I added my personal DNS server first in the /etc/resolv.conf file, so that my workstation would look first to my DNS server.
Step Two: Create and Deploy Servers
Create and deploy your public DNS servers.
Where should they be deployed? Most articles that I’ve read say that they should be on different subnets, preferably different locations, for redundancy in case of disaster.
How many name servers? The RFCs governing name servers state that one should have a minimum of three name servers. In practice I see two being predominant.
Why go to all this bother? More servers, set up correctly, and in different physical locations reduces the risk of complete failure where no DNS service is available for your machines.
How to keep the name servers in sync? PowerDNS is commonly configured with records stored in a MySQL database. One can enable database replication between machines, minimizing the amount of work required to keep the name servers in sync.
I created a master virtual machine and tested it. The virtual machine was then shut down, and copied to another hosting location 1,600 miles away from the first.
Step Three: Create the “Glue Records”
This took a fair bit of digging to understand, so forgive me if I’m a little verbose here.
Most people are familiar with the process of registering a domain name through a registrar. There’s a companion service that registrars provide, called “glue records” for DNS. It addresses the following “chicken and egg” problem:
Say you register the domain foo.com from bigregistrar.com. Next you wish to set up two authoritative name servers for foo.com called, ns1.foo.com and ns2.foo.com. When a remote machine wishes to access the name servers, it accesses the “.” root domain to access the “com” top-level domain (TLD). It asks the “com” TLD servers for the name server for foo.com and receives ns1.foo.com. Here’s the problem: in order to access foo.com, it must access ns1.foo.com. But to access ns1.foo.com, it must first locate the name server for foo.com. In other words, an irresolvable stalemate has occurred.
To resolve this problem, the registrar provides “glue” records for name servers along with the domain registration. This way the registrar is providing the IP addresses of authoritative name servers, bypassing the “chicken and egg” problem noted above.
Registrars like GoDaddy will not allow you to enter name servers that do not have these “glue” records. You’ll see something like the following “name server not registered” error message:
Managing Glue Records
Where to put this information may require a call to your registrar’s support department. It can be somewhat obscure. For example, as of today (15 February 2009) in GoDaddy’s domain manager the spot is a box on the bottom left of the page called “Host Summary”. Other nomenclature might be host handles or host objects.
In my case I was able to resolve the problem by logging into the registrar with whom I registered the domain that the name servers are under. On the management page I see the following items:
- Organization Contact
- Admin Contact
- Billing Contact
- Technical Contact
- Manage Name Servers
- … etc. …
Under this fifth item, I could find a place to enter the name servers for the domain, but not the glue records. I had to look until I noticed at the very bottom of the page text which says, “If you want to create or modify a nameserver which is based on foo.com click here“.
Clicking through, I see a page called “Manage Nameserver Hosts” where I can add names and IP addresses. For example:
Now that I’ve gone through the process and am managing my own name servers, it’s pretty straightforward (1) with good software and (2) an understanding of how things are supposed to work.
On point one, I’m not a full-time system administrator, and have struggled with BIND. From my perspective as a software engineer, it’s awful — an opaque, archaic mess.Experienced system administrators may disagree. Regardless, BIND has a learning curve. I’m far more comfortable with records in a database table.
On point two, ferreting out the glue records would not have been possible without the generous and patient assistance of the members of the pdns-users e-mail list. Thank you, all, for helping me understand the big picture.
I struggled with this and wish to pass on my learning to others who may be struggling as I was. Therefore, corrections and constructive criticism are encouraged.