Setting Up Public Name Servers


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 from Next you wish to set up two authoritative name servers for called, and 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 and receives Here’s the problem: in order to access, it must access But to access, it must first locate the name server for 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:

  1. Organization Contact
  2. Admin Contact
  3. Billing Contact
  4. Technical Contact
  5. Manage Name Servers
  6. … 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 click here“.

Clicking through, I see a page called “Manage Nameserver Hosts” where I can add names and IP addresses. For example:

Sample page for creating glue records.


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.

This entry was posted in SysAdmin and tagged , , , . Bookmark the permalink.

2 Responses to Setting Up Public Name Servers

  1. derick says:

    Thanks very much James, this has been great help.Appreciate you sharing your experience with us.Cheers

  2. Thank you for the feedback, Derick. I’m glad to hear it helped.

Leave a Reply