I wrote this article in 2011 on freevps.us. It’s a bit ghetto…pros use zone transfers. But if you’re using little 128MB VPSes for your DNS, you’re already ghetto.
Setup a DNS Nameserver Using NSD (Linux)
A nameserver does not take much memory or CPU. Indeed, once it’s setup, you’ll probably find your nameserver isn’t doing much at all, because so much is cached with other DNS servers. It just serves as the authority.
This tutorial is geared towards a super-simple DNS setup. We’ll be using NSD, a very lightweight DNS server. While the most-widely used package is BIND, BIND supports every possible option and feature, which is overkill for most people. If you just want to setup DNS for your servers and act as the authority for your domain, NSD is a much simpler solution. I’m also going to give you the basics and defaults, without getting into explaining every single option. DNS can be complex! But this will get you going on a basic setup.
Things I won’t be covering:
- reverse DNS
- zone transfers
- MX records
Here is how we’ll configure NSD:
- Two servers, each of which listen for DNS on their public interfaces.
- /etc/nsd/nsd.conf will contain the NSD configuration specific to that server
- /etc/nsd/zones will contain all the zone files (the DNS records for your domain(s))
- we’ll use rsync to keep both servers in sync. NSD supports zone transfers, but it complicates the setup and is unnecessary if all you’re doing is DNS for a few domains and it doesn’t change much. If you have a lot of DNS changes and a complex setup, then this tutorial isn’t for you 🙂
In this example, we’re setting up DNS for this configuration:
|
Of course, you can’t host DNS for example.com – only the owner of example.com can. So replace ‘example.com’ with your own domain.
I’m using CentOS but the procedure is very similar for other distros.
Step One: Install nsd
We’ll start on ns1. I recommend using your distro’s package manager. For CentOS, you will need to use the EPEL repo.
|
and then
|
Step Two: Open fireall ports
If you’re not using a firewall, you can skip this. If you’re using iptables, then you’ll need to open port 53 for udp. The exact configuration will depend on how you’ve setup your firewall, but it’ll be something that looks like this:
|
Of course, if you’re firewalling outgoing as well, you’d need to open a port on OUTPUT, too.
Step Three: Configure nsd.conf
The main config file is in /etc/nsd/nsd.conf. Here is an example. You should probably save the file that comes with nsd for future reference:
|
Now edit /etc/nsd/nsd.conf as follows:
1 |
|
Very simple!
Step Four: Configure zone_list.conf
This file is simply a list of all the zones. You could put this info in the main nsd.conf file, but our goal is to use rsync to keep the two nameservers in sync. We don’t want to rsync nsd.conf itself, because the ip-address field is unique to each server. We only want to rsync what changes, which is the zone files. So we’ll be rsyncing the zone files and the zone_list.conf, which is a list of the zone files.
The zone files can be owned by nsd or root. I have mine owned by root, so nsd can read them but not change them (in case that account is ever compromised).
|
zone_list.conf should look like this:
|
This means “there will be a zone named example.com, and you can find its records in /etc/nsd/zones/example.com”. You can define as many zones here as you want.
Step Four: Lather, Rinse, Repeat
Do steps 1-3 for ns2.example.com. The only thing you need to change is the ip-address line in /etc/nsd/nsd.conf
Step Five: Configure zone_list.conf
This is probably the most complicated part. The format of the zone file is the same one BIND uses.
Back on ns1, edit /etc/nsd/zones/example.com:
1 |
|
Well, what a lot of arcane syntax! Let’s take it line by line, but first, let me point out something very important: the dots at the end of domain names as shown here are very important. When you say “ns1.example.com.” (with the trailing dot) it means “treat that as the FQDN). If you just typed “ns1.example.com” you’d actually mean “ns1.example.com.example.com” which is not what you want 🙂
Now let’s look through the file:
|
“This is the origin of all DNS information on example.com”. This line must be first. Again, note the trailing dot.
|
TTL means “time to live” which means “other DNS servers, you should cache this for 3600 seconds (one hour)”. That is a good setting.
|
“SOA” is “Start of Authority”. @ is shorthand for “example.com.” The two names that follow it are the primary DNS server and then an email contact, rewritten in a dot notation format. In this case, admin.example.com. means “admin@example.com”.
1 |
|
Since we’re not doing zone transfers, only the ‘serial number’ really matters. But it’s important! Every time you change this file, you need to increment the serial number.
An old trick is to use a YYYYMMDDXX format, so the first change on October 23, 2011 is 2011102301, the second change on that day would be 2011102302, etc. You could of course just use 1, 2, 3, etc., but the date format is commonly done.
The point of the serial number increment is that this tells other DNS resolvers (and yours) if the file has changed. Otherwise, they don’t bother reparsing it.
I’m not going to go into the other records (refresh, retry, etc.) If you want to read up on them, try this link:
http://www.zytrax.com/books/dns/ch8/soa.html
|
These define what nameservers are valid for this domain. You need to have at least two (at least, you really should 🙂
|
Finally, we get into the actual records. Here we’ve defined three “A” records and one “CNAME” record. There are other types, but these are the most common. MX (for mail exchange) is the next most common type.
An A record is a forward DNS record. In this case, if you ask the nameserver “what is the IP address for bigvps.example.com” it will tell you “1.23.45.100”. We’ve defined three such records here.
A CNAME record is an alias. You can have as many aliases as you want. For example, you might have Apache/NGINX setup to host forum.example.com, http://www.example.com, and gallery.example.com on the same host:
|
Step Six: rsync
Now you’ve finished the zone list setup on ns1. You should have an entry for example.com in your /etc/nsd/zones/zone_list.conf file, and the above DNS record in /etc/nsd/zones/example.com file. You want to get these files to ns2. From ns1:
|
You could also use scp if you wished.
Step Seven: start nsd
On ns1, we first need to “compile” the zones and then we can start:
|
Do the same thing on ns2.
Later when you add more records, you can do this:
- Modify on ns1. Don’t forget to increment serial numbers 🙂 If you add a new domain (zone), put the corresponding zone: entry in /etc/nsd/zones/zone_list.conf
- rsync to ns2 to keep it in sync
- On both ns1 and ns2, execute “nsdc rebuild” and “nsdc reload”. This will load the changes without having to stop/start nsd.
Step Eight: Your Registrar
You’ll need to use your registrar’s web site to set the nameservers for your domain. For example.com, you need to define both the nameserver (ns1.example.com) and the IP address. For other domains you want to use ns1.example.com/ns2.example.com as DNS authorities, you just specify the DNS servers. So, for example, if you bought yahoo.com and wanted to use ns1.example.com and ns2.example.com to do the DNS, you’d set the DNS nameservers for yahoo.com to ns1.example.com and ns2.example.com (and of course create the zone file/zone list entry).
Hi, this is a comment.
To get started with moderating, editing, and deleting comments, please visit the Comments screen in the dashboard.
Commenter avatars come from Gravatar.