Bind Authoritative Caching DNS Server (named.conf)


Bind (also referred to as named) is a DNS, or domain name server daemon. Bind has the ability to locally cache dns queries as well as serve authoritative name resolution. By using a locally cached dns server you can significantly speed up local dns resolution of commonly resolved names. You can also setup a resolving dns server and assign host names to the ip address of your internal LAN machines.

A caching server helps the most when a host name is asked for many times by local clients. For example,, and are all requested many times by most users. By caching the dns query your dns server can respond with the results quickly and without having to use any external bandwidth.

An authoritative DNS server means we control names on a domain. This example will setup a local LAN with internal names on the domain called "domain.lan.

Setting up an authoritative caching DNS server is the best of both worlds. It will resolve local domain.lan names and also cache the results of external names.

BIND (Berkeley Internet Name Domain) is the most commonly used DNS server on the Internet, especially on Unix-like systems, where it is a defacto standard. Supported by Internet Systems Consortium. BIND was originally created by four graduate students with CSRG at the University of California, Berkeley and first released with 4.3BSD. Paul Vixie started maintaining it in 1988 while working for DEC.

A new version of BIND (BIND 9) was written from scratch in part to address the architectural difficulties with auditing the earlier BIND code bases, and also to support DNSSEC (DNS Security Extensions). Other important features of BIND 9 include: TSIG, DNS notify, nsupdate, IPv6, rndc flush, views, multiprocessor support, and an improved portability architecture. It is commonly used on Linux and BSD systems. Wikipedia, Bind

IMPORTANT NOTE: Do not allow external, public access to a DNS server that allows recursive lookups. To do so would expose your server to DNS cache poisoning. This example setup should only be used for internal LAN use only.

Getting Started

This exercise will setup a dns server available to the local LAN (10.10.10/24) in this example. It will cache all queries of external host names from internal clients and also serve out authoritative dns answers about our local LAN machines. This is a fully working example so you can cut/paste the examples below without issue.

By default, OpenBSD installs bind and its support files into /var/named. We will be using the same directory structure for the example. You can use the following 3 files to replace what bind installs by default. The three files we are going to cover are /var/named/etc/named.conf which is the main config file, /var/named/master/db.domain.lan the forward lookup file and /var/named/master/db.10.10.10 which is the reverse lookup file.

As you look at the config files take some time and look at all of the options. There are a lot of things to learn about bind and we are only covering a small subset. Read the man pages and join the bind discussion groups. Block out a few minutes a day and find out what a few of the named.conf options do. You may find out the options here are perfect for your uses or you may want to tweak a few. Just take your time and have fun. Bind (named) is a really good dns server.

Before using the config file take a look it in the scrollable text window below. Under the window you will find a short explanation of the lines that need your attention. If you need more information take a look at the options in the man page. This file can be saved under /var/named/etc/named.conf in the standard OpenBSD install.

// $OpenBSD:  named.conf

options {
        allow-query {; 10.10.10/24; };
        allow-recursion {; 10.10.10/24; };
        allow-transfer { none; };
      # dnssec-enable yes;
      # dnssec-validation yes;
      # dnssec-lookaside . trust-anchor;
        forward first;
        forwarders {,; };
        query-source address port *;
        listen-on {; };
        listen-on-v6 { none; };
        version "";

# trusted-keys {
# 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
# };
# Trusted key pulled from

## enable rndc commands
#controls {
#  inet allow { localhost; };

## disable rndc commands
controls { };

logging {
        category lame-servers { null; };

zone "." {
        type hint;
        file "standard/root.hint";

zone "localhost" {
        type master;
        file "standard/localhost";
        allow-transfer { localhost; };

zone "" {
        type master;
        file "standard/loopback";
        allow-transfer { localhost; };

zone "com" {
        type delegation-only;

zone "net" {
        type delegation-only;

zone "org" {
        type delegation-only;

zone "domain.lan" {
        type master;
        file "master/db.domain.lan";
        allow-update { none; };

zone "" {
        type master;
        file "master/db.10.0.10";
        allow-update { none; };

Looking at the named.conf

In the Options section we are going to setup the methods and access control lists bind will run with.

In the Logging section we are simply asking the server to log all requests except lame-servers. Those are servers who are not valid and can be ignored.

The Zone sections tell our bind server what to do when a query comes in. For example, if a query from a local machine asks for then zone "com" { type delegation-only; }; instructs our bind server to delegate the query to a "forwards" dns server. If a query comes in for one of our local machine names like host2.domain.lan then our dns server will look in the file db.domain.lan for the answer.

Looking at the locally resolving db files

Once the bind server is installed and you have the named.conf file in place you can now setup the db files for your lan. Below are two files that support forward and reverse dns lookups. You will need both files.

The first file is the db.domain.lan and is the forward resolving db file. If you ask for the ip address associated with dhcp4.domain.lan bind will look in this file and respond with the ip The forward lookup file contains A records only and has a default dns cache timeout of 86,400 seconds or 24 hours.

The scrollable text window below contains the /var/named/master/db.domain.lan

domain.lan.     86400   IN SOA  dns.domain.lan. root.dns.domain.lan. ( 1 10800 3600 6044800 86400 )
                86400   IN NS   dns.domain.lan.

dns.domain.lan.      86400   IN   A
host2.domain.lan.    86400   IN   A
host3.domain.lan.    86400   IN   A
dhcp4.domain.lan.    86400   IN   A
dhcp5.domain.lan.    86400   IN   A
dhcp6.domain.lan.    86400   IN   A
dhcp7.domain.lan.    86400   IN   A
dhcp8.domain.lan.    86400   IN   A
dhcp9.domain.lan.    86400   IN   A
dhcp10.domain.lan.   86400   IN   A
dhcp11.domain.lan.   86400   IN   A
dhcp12.domain.lan.   86400   IN   A
dhcp13.domain.lan.   86400   IN   A
dhcp14.domain.lan.   86400   IN   A

The following config is the db.10.10.10 and is considered to be the reverse lookup file. If a clients asks for the host name for the ip address named will reply with dhcp8.domain.lan. The db file contains the PTR also referred to as pointer references from the ip to the host name.

The scrollable text window below contains the /var/named/master/db.10.10.10 86400   IN SOA  dns.domain.lan. root.dns.domain.lan. ( 1 10800 3600 6044800 86400 )
                       86400   IN NS   dns.domain.lan.    86400   IN   PTR   dns.domain.lan.    86400   IN   PTR   host2.domain.lan.    86400   IN   PTR   host3.domain.lan.    86400   IN   PTR   dhcp4.domain.lan.    86400   IN   PTR   dhcp5.domain.lan.    86400   IN   PTR   dhcp6.domain.lan.    86400   IN   PTR   dhcp7.domain.lan.    86400   IN   PTR   dhcp8.domain.lan.    86400   IN   PTR   dhcp9.domain.lan.   86400   IN   PTR   dhcp10.domain.lan.   86400   IN   PTR   dhcp11.domain.lan.   86400   IN   PTR   dhcp12.domain.lan.   86400   IN   PTR   dhcp13.domain.lan.   86400   IN   PTR   dhcp14.domain.lan.

Starting Bind

To start bind manually execute the daemon using "named -4". To start Bind (named) at boot you can edit your /etc/rc.conf.local file and put in the following line. If you have not made a rc.conf.local file you can always edit the /etc/rc.conf file and put the "-4" option in the named directive. The "-4" argument will simply start bind and listen to ipv4 address only.


HELPFUL HINT: Check out our DNS Verify (ip to hostname to ip) script. It will help you verify your hostnames match your ip addresses and spot any problems in name resolution.


Do you support the use of SRV dns records?

Absolutely! SRV records allow one to specify a priority, weight and port to a service or protocol through dns records. For example, what if we wanted all web traffic to to come in on port 8080 because our ISP blocks ports 80 and 443? We would set the service to "_http.", the protocol type to "_tcp." and the host to "". Then we could specify "0 0 8080" for priority=0, weight=0 and port=8080 and the target hostname "". Our finally record would look like " has SRV record 0 0 8080" This would clearly tell any client looking to connect to's http web server to connect on port 8080. Simple and efficient.

The biggest problem with SRV records are that they are just not widely supported. SRV has been around since the year 2000 and developers (Firefox, Microsoft, and many many others) just do not support it. This is a really shame because SRV records are just _so_ incredibly useful.

Here is an example our's public SRV records. These say that's mail server is found at and the web server is at and for SSL encrypted pages. Even though we are using the standard ports for our services we could use any ports we want to (port 12345 for http for example) if all clients supported SRV record lookups.

user@machine: host -t srv has SRV record 0 0 25

user@machine: host -t srv has SRV record 0 0 80

user@machine: host -t srv has SRV record 0 0 443

Want to check your resolver's source port behavior?

To see if your version of BIND (named) is vulnerable to the latest "Birthday (CERT VU#800113)" vulnerability please goto dns-oarc. This will allow you to test the standard deviation of ports your DNS server used to access their DNS resolver.

How can I find a fast dns server to use for my "forwarders"?

Ideally you want to use the local dns servers of your isp as they should be the fastest you have access to. You DO NOT want to use the root dns servers as they are not for individual use. You want to find local tier 3 dns servers like what your isp offers to you.

In the example we used two Google Public DNS servers ( and ) because they resolve quickly and are geographically close to the server. You may want to use dns servers other than your isp to help anonymize browsing. Check out the OpenDNS site as well to find out more about their other free services like adult site blocking, phishing site blocks and statistics.

To test if the dns server for your isp or OpenDNS is performing better than others you can use the "dig" command. Here we see that a dns query for "" pointed at each individual OpenDNS server return results in 11 to 25 milliseconds. Try to find dns servers that will respond in less than 50ms.

user@machine: dig @ | grep "Query time"
;; Query time: 11 msec

user@machine: dig @ | grep "Query time"
;; Query time: 25 msec

How do I turn off Firefox's caching ability?

If you dislike Firefox's caching behavior (cache expires in 24 hours) and your name server's cache just fine then disable all caching in the browser. Firefox's cache is just another level of expirations to go through. Here's the cross-platform method, if you should wish to do so:
In about:config, add two new integer entries:             
  network.dnsCacheExpiration  -> 0
  network.dnsCacheEntries     -> 0

Questions, comments, or suggestions? Contact