DNS Setup: The Pitfall of Bind

DNS can be a vastly complicated thing, particularly setting up Bind the most common DNS server product in use. However, it doesn’t have to be scary.

In this post I’ll go through setting up Bind and configuring a test domain. If you’re not sure what DNS is or how it works, hit up Google and find out. This article by How Stuff Works isn’t too bad an overview either.

For my DNS setup, I run Bind as the master server, and have an account with EasyDNS for additional DNS servers that synchronise changes from the master server to their copy. This is more commonly known as a Secondary DNS.

Picture time! (I like pictures).

Overview of my DNS Setup

What happens when a DNS request comes in (say you want to load this blog), is that your ISP’s DNS servers will lookup the name servers for my domain, which would return one of the four options above. At that point your ISP’s DNS server will pick one at random and ask it for the IP address of my blog (known as an A record). Your computer can then connect directly to the server and open the blog.

Each of the EasyDNS servers listed above is actually an anycast constellation, which means it has four or five DNS servers spread across the globe. For example, at the time of writing, the EasyDNS 1 constellation had servers in Ashburn, Chicago, San Jose, Amsterdam and Tokyo.

The EasyDNS servers stay in sync through a method called a zone transfer. When I update the records on Shana, she will send a message to the EasyDNS transfer server that there is an update available for a specific domain. EasyDNS then requests a zone transfer to grab the most recent copy of the DNS records for that domain and updates their local server records.

Installing Bind

That’s probably enough of an overview of my setup for now, lets get cracking on installing and configuring Bind. Fortunately, we don’t have to do anything here, Bind is already installed by default on FreeBSD.

It is worth noting here that the service/daemon that runs is actually called named. From here on out I’ll refer to everything using named as the product name “Bind” is rarely mentioned.

Configuring Named

As it is already installed, you can imagine that a good chunk of the setup is already done for you too. This is true, all of the named configuration files can be found in /etc/namedb/. Lets check what we have in there.

You might notice too that the dynamic, slave and working directories are owned and writable by the bind user. That is because named will write to these directories itself.

For this post, we’re only really interested in the named.conf file and the master subdirectory.

General Configuration

There are a few general setup items we need to change, these all exist inside the options directive.

Firstly, turn recursion off for an authoritative server. We don’t need to be serving requests from users for domains that we are not authoritative for. While it is unlikely someone will try to use us for recursive DNS, it is still a waste of CPU cycles and network if they do.

recursion no;

Secondly, if we’re serving domains we need to listen on the external IP address, otherwise no one can reach us.

listen-on { 127.0.0.1;; };

Adding a Zone

Time to add our test zone! We’ll go ahead and setup a fake somedomain.com for testing named.

Creating the Zone in named.conf

Add the following to the bottom of your /etc/namedb/named.conf file.

// somedomain.com - A Test domain
zone "somedomain.com" {
type master;
file "/etc/namedb/master/somedomain.com";
zone-statistics true;

allow-transfer { ww.xx.yy.zz; };
also-notify { ww.xx.yy.zz; };
};

Please be very specific about the placement of your semicolons (;), otherwise it will fail. In more detail:

zone "somedomain.com" {

This line starts a zone record, with the domain name of the zone. In this case it is somedomain.com.

type master;

The type of zone, we want to be authoritative and returns results for this zone, so we’re the master.

file "/etc/namedb/master/somedomain.com";

This line tells named where to find the file that contains the DNS records for that zone.

zone-statistics true;

I enable zone statistics on my zones for reporting and dashboards. With a simple script I can see how many requests are being served for this domain, etc. More detail on how to do this will follow in a later post.

allow-transfer { ww.xx.yy.zz; };

By default, zone transfers are not allowed for any domain. This is for security reasons mostly as there is no need to let clients know all of the records you have. They might find your porn server, for instance. This line will allow specific IP Addresses to request a zone transfer for this domain.

also-notify { ww.xx.yy.zz; };

To take it the step further, this line will cause named to notify the IP address(es) listed whenever the serial number on this zone is updated.

For a better overview of how your named.conf file works and the configuration options available, check out this guide from CentOS.

Creating the Zone File

I generally name the files in my master/ subdirectory the same as the domain name themselves. Lets create our somedomain.com file and we’ll step through what it means.

;
; somedomain.com Zone File
;
; Created: 6 July 2012
; By: Rob Amos
;
$ORIGIN somedomain.com.
$TTL 6h

@ IN SOA shana.somedomain.com. postmaster.somedomain.com (
2012070601 ; serial number
1h ; refresh time
30m ; retry values
7d ; record cache expiry
1h ; minimum time to cache
)

; Name Servers
NS shana.somedomain.com.

; Mail Servers
MX 5 shana.somedomain.com.

; SPF Record
TXT "v=spf1 mx:somedomain.com ~sll"

; Subdomains
A 172.16.0.4
shana A 172.16.0.4
www CNAME shana.somedomain.com.

And in some more detail:

$ORIGIN somedomain.com.

The $ORIGIN record is the domain that would be appended to any unqualified records. Meaning that if you wrote subdomain instead of subdomain.somedomain.com, then the somedomain.com would be appended automatically.

$TTL 6h

Our $TTL (Time to Live) value tells servers how long these records should remain valid for.

@ IN SOA shana.somedomain.com. postmaster.somedomain.com (
2012070601 ; serial number
1h ; refresh time
30m ; retry values
7d ; record cache expiry
1h ; minimum time to cache
)

This is our Start of Authority record, more commonly known as the SOA. This provides information about the authoritative server and zone information for this domain. Read this guide for more info, but I will suggest you set the serial number to today’s date plus a two digit counter that you increment the more times you change it during that day.

The serial number is especially important when you’ve got slave or secondary name servers. They use the serial number to know whether they need to update your domain, so make sure you increment the serial number every time you make a change.

NS shana.somedomain.com.

A name server record, there should be one of these for each of your servers, the order doesn’t matter.

MX 5 shana.somedomain.com.

A Mail Exchange (MX) record. This tells email clients where to find your mail server. The number indicates the priority of the server record with the lowest number having the highest priority. Note the trailing dot (.), it is very important. If you do not put that there named will append $ORIGIN to the listed name.

TXT "v=spf1 mx:somedomain.com ~all"

An SPF record. This one says that only the MX record for subdomain.com is allowed to send email for somedomain.com. Microsoft has a handy tool to generate SPF records.

A 172.16.0.4
shana A 172.16.0.4

Address (A) records. This maps a subdomain to an IP address. It is useful to note that column left blank will use the record before it. So we left the first column blank for all records until shana. That means it used the last one listed, which was the @ symbol. The @ refers to the domain itself, not a subdomain.

Likewise the second column (IN) is missing, its reused from above. So you could rewrite that second like this if you wanted.

@ IN NS shana.somedomain.com.
@ IN MX 5 shana.somedomain.com.
@ IN TXT "v=spf1 mx:somedomain.com ~all"
@ IN A 172.16.0.4
shana IN A 172.16.0.4

One last one – a CNAME or alias record. Note the trailing dot again. This one will make www.somedomain.com an alias of shana.somedomain.com.

www CNAME shana.somedomain.com.

Once again, the CentOS guide has a good step by step and breakdown with more information on the Zone Files beyond my examples.

Testing our Setup

That’s effectively everything you need to setup. Enable named in your /etc/named.conf file and lets test it out.

named_enable="YES"

Starting named:

Check the logs to see if it was ok:

And testing our resolution:

All done! A simple post this time.