Archive for March, 2011

DNS on OpenBSD

Posted in OpenBSD, Tutorials on March 24, 2011 by anzuthechosen


In this guide, I will be doing a step-by-step walkthrough on how to successfully setup a Domain Name Server on an OpenBSD platform. I will try to make this as easy to follow and simple as possible, while attempting to cover all the important aspects of setting up DNS. However, you should have a decent understanding of how DNS works and also how to navigate around a Unix-like operating system.

Why OpenBSD for DNS?

As you probably know, OpenBSD is one of the most secure operating systems on this planet. Considering the extremely low occurrence of vulnerabilities in its default releases over the years, OpenBSD makes the security conscious network administrator’s job a little bit easier. It’s also been designed very efficiently as far as handling tasks and updates goes, which is essential when it comes to any type of server platform. Domain Name Servers are the most important servers on a lot of networks. They are crucial instruments for websites, email servers, other common network services. So, common sense dictates that the most integral and vital services on a network should be run on the most reliable and secure platform available. Furthermore, the extraordinarily helpful and constructive communities surrounding OpenBSD (and FreeBSD) make solving problems and implementing new ideas a fun and enlightening experience.

Things You Need:

  1. OpenBSD – duh! I’ll be using OpenBSD 4.8 Release (current as of writing)
  2. Domain Name Service or Daemon – I’ll be using BIND in this tutorial
  3. Will to learn – Probably the most important thing you’ll need, and not just for this project either

And that’s it!

To begin with, we won’t need all the default install sets for OpenBSD. In fact, I am only going to be installing the following install sets:

  • bsd – the kernel; we definitely need this ^_^
  • bsd.rd – RAM disk kernel, good for emergencies
  • base48.tgz – base OpenBSD system
  • etc48.tgz – everything from /etc ; definitely need this
  • misc48.tgz – setup documentation, misc. info; optional
  • comp48.tgz – compiler, headers, libraries, etc; you might want this
  • man48.tgz – man pages; always a good thing to have!

Note: If you are running this on a multi-processor system, you should also select the bsd.mpinstall set.

You might be able to get by with less than that, but in an effort to keep things simple and easy, we will just stick with those sets. Also, since we will be doing all setup from command line, we will not be installing X11 or any kind of desktop (also saves drive space). As a general rule: if a program or service is not specifically required by your server (especially DNS), you shouldn’t have it on there.

Step 1: Basic Network Configuration Files

First and foremost, before we start looking at the BIND configuration files, you need to have the appropriate host name and network configuration setup correctly. For the most part, I’m going to assume you know how to setup basic networking in OpenBSD (if not, read this). So, I will just touch on the most important files to get DNS working properly. In OpenBSD, this consists of setting up the following network configuration files:

/etc/myname – Contains hostname, in the following format:


Here’s an example of my /etc/myname

/etc/hosts – Contains hostnames, with references to their IP addresses. Follows this basic format: localhost

Here’s an example of my /etc/hosts

/etc/hostname.if – Interface configuration file. Follows the basic format:


Here’s an example of my /etc/hostname.if Note: My config file is named /etc/hostname.em0 , because my network interface is called em0. Also note that in OpenBSD, interface names correspond to the type of card, unlike in Linux where they are named according to the type of connection. So, your interface might be called fxp0 , making your hostname file /etc/hostname.fxp0

/etc/mygate – Specifies default gateway. Follows the format:

It’s just one line with an IP address (your gateway’s IP); do you really need an example? =P My OpenBSD DNS server is on a closed network, therefore I have not created a /etc/mygatefile.

/etc/resolv.conf – Contains name server and domain information. Follows this basic format:

search nameserver nameserver lookup file bind

Here’s an example of my /etc/resolv.conf Note: The text lookup file bind in this file should be taken into account. It specifies that the local /etc/hosts file will be consulted before trying to resolve through the name servers. For more information on resolv.conf, check out this link Step 2: Name Server Configuration

Here’s where we start getting into the actual DNS configuration for the name server. There are really only a couple types of files that need to be setup to get your name server resolving correctly. I will try to be as thorough and descriptive as possible, however if you’re not sure about something, please refer to the OpenBSD Man pages, FAQ, and the BIND documentation.

named.conf – This is the main BIND configuration file. In OpenBSD, this file is located in /var/named/etc by default. Differing from Linux, OpenBSD puts BIND into a chrooted environment under /var/named/ . This file specifies options for the DNS zones and their respective config files, as well as some other options. The following is an example of my named.conf with an explanation of each part afterward (please note that this is a very basic configuration):

Here’s an example of my named.conf Important Parts: Options

options { version “”; directory “/”;

Specify what version of BIND to report to anyone who asks. Leave blank for nothing. Then, set directory to be used for relative root path. Remember, BIND runs chrooted on OpenBSD, so this actually translates to /var/named/.

# listen-on {; }; listen-on { any; }; listen-on-v6 { any; }; };

Set BIND to listen on all network interfaces, IPv4 and IPv6. You could use this first line to tell BIND to only listen on the interface with IP address .

This is where global options for BIND are configured. Comments are preceded by a #. Here we have set the directory to be used for relative path resolution and told BIND which interfaces to listen on (all of them). There are lots of other options that can be configured, depending on your network setup. My example named.conf contains only the basic configuration options, just enough to get it up and running.


// Master Zones # Specify zone name zone “hell.local” { # Specify zone type type master; # Specify zone data file file “master/hell.local”; # Don’t allow Zone Transfers, period. allow-transfer { none; }; }; // Slave Zones zone “heaven.local” { type slave; file “slave/heaven.local”; masters {; };

Here we have a simple zone setup. The master zone is hell.local and is configured by the data file master/hell.local . It is good practice to keep your zone data files organized in folders (i.e. master zone files in master folder, slave zone files in slave folder). Take note of the allow-transfer line. This option is important because it defines the address range to allow Zone Transfers to. Normally, you would enter the address of your secondary DNS server. But I have no secondary DNS server, so it is set to none.

Even though my example setup does not include a slave zone, I have included a sample slave zone setup above to give you an idea of how it works. Comments are preceded by # or // in this example.

Step 3: Zone Files

This is pretty much the most important aspect of DNS configuration. Zone files are where you specify which parts of your network your server will answer queries for. The syntax of the zone file may seem a bit daunting at first, but in reality it is quite simple. In the following example, I’ll explain each section of the file. So, let’s get right into it:

Here’s my hell.localfile for reference


$TTL 12h

The default lifespan of a DNS record, 12 hours. Adjust based on your network preferences. Set to longer value to reduce network load, shorter value for changes to propagate faster

$ORIGIN hell.local.

The default value which is added to unqualified domain names and is substituted in place of the @ symbol.

@ IN SOA evildns.hell.local. satan.hell.local. (

The above line is the Start Of Authority record, which begins with the @ symbol, representing the hell.local. domain, then IN which specifies the Internet Protocol class, SOA states that this is the SOA record type, evildns.hell.local. is the authoritative name server for this zone, and satan.hell.local.represents the email address of the administrator with a “.” substituted for the normal @ symbol.


Serial number, usually takes format of yyyymmdd##


Refresh interval, 3 hours


Retry delay, 1 hour


Expiration time, 1 week

1h )

Minimum caching time for fails, 1 hour

hell.local. IN NS evildns

This is a Name Server (NS) record. It specifies my DNS server evildns for the domain hell.local..

evildns IN A bsdvm IN A www IN A win7vm IN A winxpvm IN A

These are all Address (A) records, which point host names to IPv4 addresses. Note: In zone files, some places require you to enter a fully qualified domain name, with a trailing “.” . Take note of the places in this example that have trailing periods after the domain name and remember they are needed. Also, note that email addresses are displayed differently in this file. For instance, becomes

So that’s all there is to a basic zone data file. If you take away the comments, there really isn’t a whole lot of text to it. There are other record types that you should be familiar with if you are going to be administering DNS servers, but I won’t go into detail about them here. For more information about DNS records, check out these links: Record Types , DNS Parameters , & RFC 1035 .

There are some other zone data files that are recommended for your network. These files are referred to in the named.conf and specify reverse lookup and localhost zones. Having these files configured will prevent unnecessary queries being sent to the root domain servers. These files include db.0 , db.255 , localhost , loopback , and . Here are examples of these files from my server: db.0, db.255, locahost, loopback,

Finally, to make sure BIND starts at boot you’re going to need the following lines somewhere in your rc.conffile:

# Pass flags to named named_flags=”” # User to run BIND as named_user=named # Root directory for BIND named_chroot=/var/named

Now, all that’s left to do is to point your clients to your new DNS server and you can start resolving hostnames! To test your DNS server, issue the following command from a shell on your client:

nslookup hostname.domain

Replacing the hostname.domain with the hostname of a client on your domain. Check to see if the DNS server was queried and whether it returned the correct IP address. If it did, congratulations on setting up your OpenBSD DNS server correctly! =D


Hello world!

Posted in Uncategorized on March 23, 2011 by anzuthechosen

Greetings 🙂

Welcome to my computer and network security blog!  As you can probably guess by the lack of content, I’ve just started this blog, but I will be adding posts as time goes on covering all things computer, network security, and IT related.  So pretty much anything that interests me as well as my latest projects will be posted on here for all to see.

Maybe my blog will help some of you with your own projects, or maybe you’re just looking for some IT related material to read in your spare time.  Either way, I’m glad you came and hope that you enjoy what you see.