// Tutorial //

How To Configure Bind as a Caching or Forwarding DNS Server on Ubuntu 14.04

Published on July 1, 2014
Default avatar
By Justin Ellingwood
Developer and author at DigitalOcean.
How To Configure Bind as a Caching or Forwarding DNS Server on Ubuntu 14.04
Not using Ubuntu 14.04?Choose a different version or distribution.
Ubuntu 14.04

Introduction


DNS, or the Domain Name System, is often a difficult component to get right when learning how to configure websites and servers. While most people will probably choose to use the DNS servers provided by their hosting company or their domain registrar, there are some advantages to creating your own DNS servers.

In this guide, we will discuss how to install and configure the Bind9 DNS server as a caching or forwarding DNS server on Ubuntu 14.04 machines. These two configurations both have advantages when serving networks of machines.

Prerequisites and Goals

To complete this guide, you will first need to be familiar with some common DNS terminology. Check out this guide to learn about some of the concepts we will be implementing in this guide.

We will be demonstrating two separate configurations that accomplish similar goals: a caching and a forwarding DNS server.

To follow along, you will need to have access to two computers (at least one of which should be an Ubuntu 14.04 server). One will function as the client and the other will be configured as the DNS server. The details of our example configuration are:

Role IP Address
DNS Server 192.0.2.1
Client 192.0.2.100

We will show you how to configure the client machine to use the DNS server for queries. We will show you how to configure the DNS server in two different configurations, depending on your needs.

Caching DNS Server

The first configuration will be for a caching DNS server. This type of server is also known as a resolver because it handles recursive queries and generally can handle the grunt work of tracking down DNS data from other servers.

When a caching DNS server tracks down the answer to a client’s query, it returns the answer to the client. But it also stores the answer in its cache for the period of time allowed by the records’ TTL value. The cache can then be used as a source for subsequent requests in order to speed up the total round-trip time.

Almost all DNS servers that you might have in your network configuration will be caching DNS servers. These make up for the lack of adequate DNS resolver libraries implemented on most client machines. A caching DNS server is a good choice for many situations. If you do not wish to rely on your ISPs DNS or other publicly available DNS servers, making your own caching server is a good choice. If it is in close physical proximity to the client machines, it is also very likely to improve the DNS query times.

Forwarding DNS Server

The second configuration that we will be demonstrating is a forwarding DNS server. A forwarding DNS server will look almost identical to a caching server from a client’s perspective, but the mechanisms and work load are quite different.

A forwarding DNS server offers the same advantage of maintaining a cache to improve DNS resolution times for clients. However, it actually does none of the recursive querying itself. Instead, it forwards all requests to an outside resolving server and then caches the results to use for later queries.

This lets the forwarding server respond from its cache, while not requiring it to do all of the work of recursive queries. This allows the server to only make single requests (the forwarded client request) instead of having to go through the entire recursion routine. This may be an advantage in environments where external bandwidth transfer is costly, where your caching servers might need to be changed often, or when you wish to forward local queries to one server and external queries to another server.

Install Bind on the DNS Server

Regardless of which configuration choice you wish to use, the first step in implementing a Bind DNS server is to install the actual software.

The Bind software is available within Ubuntu’s default repositories, so we just need to update our local package index and install the software using apt. We will also include the documentation and some common utilities:

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

Now that the Bind components are installed, we can begin to configure the server. The forwarding server will use the caching server configuration as a jumping off point, so regardless of your end goal, configure the server as a Caching server first.

Configure as a Caching DNS Server

First, we will cover how to configure Bind to act as a caching DNS server. This configuration will force the server to recursively seek answers from other DNS servers when a client issues a query. This means that it is doing the work of querying each related DNS server in turn until it finds the entire response.

The Bind configuration files are kept by default in a directory at /etc/bind. Move into that directory now:

cd /etc/bind

We are not going to be concerned with the majority of the files in this directory. The main configuration file is called named.conf (named and bind are two names for the same application). This file simply sources the named.conf.options file, the named.conf.local file, and the named.conf.default-zones file.

For a caching DNS server, we will only be modifying the named.conf.options file. Open this in your text editor with sudo privileges:

sudo nano named.conf.options

With the comments stripped out for readability, the file looks like this:

options {
        directory "/var/cache/bind";

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

To configure caching, the first step is to set up an access control list, or ACL.

As a DNS server that will be used to resolve recursive queries, we do not want the DNS server to be abused by malicious users. An attack called a DNS amplification attack is especially troublesome because it can cause your server to participate in distributed denial of service attacks.

A DNS amplification attack is one way that malicious users try to take down servers or sites on the internet. To do so, they try to find public DNS servers that will resolve recursive queries. They spoof the victim’s IP address and send a query that will return a large response to the DNS server. In doing so, the DNS server responds to a small request with a large payload directed at the victims server, effectively amplifying the available bandwidth of the attacker.

Hosting a public, recursive DNS server requires a great deal of special configuration and administration. To avoid the possibility of your server being used for malicious purposes, we will configure a list of IP addresses or network ranges that we trust.

Above the options block, we will create a new block called acl. Create a label for the ACL group that you are configuring. In this guide, we will call the group goodclients.

acl goodclients {
};

options {
    . . .

Within this block, list the IP addresses or networks that should be allowed to use this DNS server. Since both our server and client are operating within the same /24 subnet, we will restrict the example to this network. We will also add localhost and localnets which will attempt to do this automatically:

acl goodclients {
    192.0.2.0/24;
    localhost;
    localnets;
};

options {
    . . .

Now that we have an ACL of clients that we want to resolve request for, we can configure those capabilities in the options block. Within this block, add the following lines:

options {
    directory "/var/cache/bind";

    recursion yes;
    allow-query { goodclients; };
    . . .

We explicitly turned recursion on, and then configured the allow-query parameter to use our ACL specification. We could have used a different parameter, like allow-recursion to reference our ACL group. If present and recursion is on, allow-recursion will dictate the list of clients that can use recursive services.

However, if allow-recursion is not set, then Bind falls back on the allow-query-cache list, then the allow-query list, and finally a default of localnets and localhost only. Since we are configuring a caching only server (it has no authoritative zones of its own and doesn’t forward requests), the allow-query list will always apply only to recursion. We are using it because it is the most general way of specifying the ACL.

When you are finished making these changes, save and close the file.

This is actually all that is required for a caching DNS server. If you decided that this is the server type you wish to use, feel free to skip ahead to learn how to check your configuration files, restart the service, and implement client configurations.

Otherwise, continue reading to learn how to set up a forwarding DNS server instead.

Configure as a Forwarding DNS Server

If a forwarding DNS server is a better fit for your infrastructure, we can easily set that up instead.

We will start with the configuration that we left off in the caching server configuration. The named.conf.options file should look like this:

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

We will be using the same ACL list to restrict our DNS server to a specific list of clients. However, we need to change the configuration so that the server no longer attempts to perform recursive queries itself.

To do this, we do not change recursion to no. The forwarding server is still providing recursive services by answering queries for zones it is not authoritative for. Instead, we need to set up a list of caching servers to forward our requests to.

This will be done within the options {} block. First, we create a block inside called forwarders that contains the IP addresses of the recursive name servers that we want to forward requests to. In our guide, we will use Google’s public DNS servers (8.8.8.8 and 8.8.4.4):

. . .
options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        . . .

Afterward, we should set the forward directive to “only” since this server will forward all requests and should not attempt to resolve requests on its own.

The configuration file will look like this when you are finished:

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        forward only;

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

One final change we should make is to the dnssec parameters. With the current configuration, depending on the configuration of forwarded DNS servers, you may see some errors that look like this in the logs:

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53

To avoid this, change the dnssec-validation setting to “yes” and explicitly enable dnssec:

. . .
forward only;

dnssec-enable yes;
dnssec-validation yes;

auth-nxdomain no;    # conform to RFC1035
. . .

Save and close the file when you are finished. You should now have a forwarding DNS server in place. Continue to the next section to validate your configuration files and restart the daemon.

Test your Configuration and Restart Bind

Now that you have your Bind server configured as either a caching DNS server or a forwarding DNS server, we are ready to implement our changes.

Before we take the plunge and restart the Bind server on our system, we should use Bind’s included tools to check the syntax of our configuration files.

We can do this easily by typing:

sudo named-checkconf

If there are no syntax errors in your configuration, the shell prompt will return immediately without displaying any output.

If you have syntax errors in your configuration files, you will be alerted to the error and line number where it occurs. If this happens, go back and check your files for errors.

When you have verified that your configuration files do not have any syntax errors, restart the Bind daemon to implement your changes:

sudo service bind9 restart

Afterwards, keep an eye on the server logs while you set up your client machine to make sure that everything goes smoothly. Leave this running on the server:

sudo tail -f /var/log/syslog

Now, open a new terminal window to configure your client machines.

Configure the Client Machine

Now that you have your server up and running, you can configure your client machine to use this DNS server for queries.

Log into your client machine. Make sure that the client you are using was specified in the ACL group you set for your DNS server. Otherwise the DNS server will refuse to serve requests for the client.

We need to edit the /etc/resolv.conf file to point our server to the name server. Changes made here will only last until reboot, which is great for testing. If we are satisfied with the results of our tests, we can make these changes permanent.

Open the file with sudo privileges in your text editor:

sudo nano /etc/resolv.conf

The file will list the DNS servers to use to resolve queries by setting the nameserver directives. Comment out all of the current entries and add a nameserver line that points to your DNS server:

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

Save and close the file.

Now, you can test to make sure queries can resolve correctly by using some common tools.

You can use ping to test that connections can be made to domains:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

This means that our client can connect with google.com using our DNS server.

We can get more detailed information by using DNS specific tools like dig. Try a different domain this time:

dig linuxfoundation.org
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.		IN	A

;; ANSWER SECTION:
linuxfoundation.org.	6017	IN	A	140.211.169.4

;; Query time: 36 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE  rcvd: 64

You can see that the query took 36 milliseconds. If we make the request again, the server should pull the data from its cache, decreasing the response time:

dig linuxfoundation.org
; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.		IN	A

;; ANSWER SECTION:
linuxfoundation.org.	6012	IN	A	140.211.169.4

;; Query time: 1 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE  rcvd: 64

As you can see, the cached response is significantly faster.

We can also test the reverse lookup by using the IP address that we found (140.211.169.4 in our case) with dig’s -x option:

dig -x 140.211.169.4
; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN	CNAME	4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN	PTR	load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE  rcvd: 117

As you can see, the reverse lookup also succeeds.

Back on your DNS server, you should see if any errors have been recorded during your tests. One common error that may show up looks like this:

. . .
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53

These indicate that the server is trying to resolve IPv6 information but that the server is not configured for IPv6. You can fix this issue by telling Bind to only use IPv4.

To do this, open the /etc/default/bind9 file with sudo privileges:

sudo nano /etc/default/bind9

Inside, modify the OPTIONS parameter to include the -4 flag to force IPv4 only behavior:

OPTIONS="-u bind -4"

Save and close the file.

Restart the server:

sudo service bind9 restart

You should not see these errors in the logs again.

Making Client DNS Settings Permanent

As mentioned before, the /etc/resolv.conf settings that point the client machine to our DNS server will not survive a reboot. To make the changes last, we need to modify the files that are used to generate this file.

If the client machine is running Debian or Ubuntu, open the /etc/network/interfaces file with sudo privileges:

sudo nano /etc/network/interfaces

Look for the dns-nameservers parameter. You can remove the existing entries and replace them with your DNS server or just add your DNS server as one of the options:

. . .
iface eth0 inet static
        address 111.111.111.111
        netmask 255.255.255.0
        gateway 111.111.0.1
        dns-nameservers 192.0.2.1
. . .

Save and close the file when you are finished. Next time you boot up, your settings will be applied.

If the client is running CentOS or Fedora, you need to open the /etc/sysconfig/network/network-scripts/ifcfg-eth0 file instead:

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

Inside, look for the lines that begin with DNS. Change DNS1 to your DNS server. If you don’t want to use the other DNS servers as a fallback, remove the other entries:

DNS1=192.0.2.1

Save and close the file when you are finished. Your client should use those settings at next boot.

Conclusion

You should now have either a caching or forwarding DNS server configured to serve your clients. This can be a great way to speed up DNS queries for the machines you are managing.

If you want to create a DNS server that is authoritative for your own domain zones, you can configure an authoritative-only DNS server or combine these solutions.


Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in our Questions & Answers section, find tutorials and tools that will help you grow as a developer and scale your project or business, and subscribe to topics of interest.

Sign up

Tutorial Series: An Introduction to Managing DNS

DNS, or the domain name system, is an essential component of modern internet communication. It allows us to reference computers by names instead of IP addresses. In this series, we will cover the basic ideas behind DNS so that you feel comfortable working with it. Afterwards, we will walk through various ways that you can gain greater control over your domains and DNS resolution.

About the authors
Default avatar
Developer and author at DigitalOcean.

Still looking for an answer?

Was this helpful?
10 Comments

Hi guys,

I am facing a strange behavior by Bind9. I am working in mixed environment (windows and linux cleint and server machines). I have recently configured a Bind9 as a private/internal DNS server. It’s working fine with windows clients but unable to ping the linux machines. However, nslookup does resolve the linux hosts. Following is the configuration files.

$ sudo cat /etc/bind/named.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, BEFORE you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local

include “/etc/bind/named.conf.options”; include “/etc/bind/named.conf.local”; include “/etc/bind/named.conf.default-zones”;

$ sudo cat /etc/bind/named.options

options { directory “/var/cache/bind”;

    // If there is a firewall between you and nameservers you want
    // to talk to, you may need to fix the firewall to allow multiple
    // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

    // If your ISP provided one or more IP addresses for stable
    // nameservers, you probably want to use them as forwarders.
    // Uncomment the following block, and insert the addresses replacing
    // the all-0's placeholder.

    // forwarders {
    //      0.0.0.0;
    // };

    //========================================================================
    // If BIND logs error messages about the root key being expired,
    // you will need to update your keys.  See https://www.isc.org/bind-keys
    //========================================================================
    allow-query { localhost; 10.0.0.0/24; };
    allow-transfer { localhost; 10.0.0.0/24; };
    allow-recursion { localhost; 10.0.0.0/24; };
    dnssec-validation auto;

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { none; };

};

$ sudo cat /etc/bind/named.conf.local

// // Do any local configuration here //

// Consider adding the 1918 zones here, if they are not used in your // organization //include “/etc/bind/zones.rfc1918”; zone “test.local” { type master; file “/etc/bind/db.test.local”; };

zone “0.0.10.in-addr.arpa” { type master; file “/etc/bind/db.10”; };

Zone files details.

// // If you are just adding zones, please do that in /etc/bind/named.conf.local

include “/etc/bind/named.conf.options”; include “/etc/bind/named.conf.local”; include “/etc/bind/named.conf.default-zones”;

$ sudo cat /etc/bind/db.test.local

; BIND reverse data file for empty rfc1918 zone ; ; DO NOT EDIT THIS FILE - it is used for multiple zones. ; Instead, copy it, edit named.conf, and use that copy. ; $TTL 86400

@ IN SOA ns1.test.local. root.test.local. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL ; IN NS ns1.test.local IN A 10.0.0.88 ;A Records ns1 IN A 10.0.0.88

;Linux host A record. host1 IN A 10.0.0.80

;Windows host A record. host2 IN A 10.0.0.81

$ sudo cat /etc/bind/db.10 ; BIND reverse data file for empty rfc1918 zone ; ; DO NOT EDIT THIS FILE - it is used for multiple zones. ; Instead, copy it, edit named.conf, and use that copy. ; $TTL 86400

@ IN SOA ns1.test.local. root.test.local. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL ; IN NS ns1.test.local. IN A 255.255.255.0 88 IN PTR test.local 80 IN PTR host1. 81 IN PTR host2.

Windows clients are communicating 100% perfect nslookup and ping both are fine but when I use to ping a linux client machine the message I get is

“C:\Users\userq>ping host1 Ping request could not find host host1. Please check the name and try again.”

However nslookup resolve the name.

How to diagnose it. Thanks in advance.

Thank you so much for this wonderful tutorial. I am implementing DNS Sandbox as a part of Masters Project. I’m replicating the entire Domain Name Servers by implementing my own set of domains (ex: ex1.example.test.nik) in cloudlab using linux VMs. In this implementation, I have implemented my own root(.) server, TLD(nik) server, Secondary Level Domain(test) server and Ternary Level Domain(example). I am also implementing recursive resolver(which is explained here as Caching DNS Server) and stub resolver.

Right now, I am stuck up with the implementation of the Recursive resolver. Any help would be highly appreciated. Could you please let me know how to configure Recursive Resolver(RR) - I mean how will it contact the root server? Where should I mention the information(IP) of root server in RR’s configuration file?

Any sort of help or guidance is highly appreciated. Please let me know if you need more details of my implementation.

Ubuntu 15.10 with LAMP I just, successfully, installed OpenVPN on a fresh droplet. I like the idea of having a DNS cache from both privacy and speed points of view, so I followed this tutorial in an attempt to get this. What I know about DNS is somewhere between nada and nada+0.5. Now my DNS is all f&*ked up. DNSLeaktest shows my apt’s ip instead of the VPN’s. Everything else takes an age to resolve. IP’s between my clients and my droplet (which has openVPN and the DNS server) are a mystery to me and so probably the problem.

Not sure what log info to include, here’s some if more helps please ask…

Thanks.

<syslog> Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> (eth1): DHCPv4 state changed unknown -> timeout Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> (eth1): canceled DHCP transaction, DHCP client pid 3986 Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> (eth1): DHCPv4 state changed timeout -> done Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> (eth1): device state change: ip-config -> failed (reason ‘ip-config-unavailable’) [70 120 5] Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> Connection ‘Wired connection 1’ failed to autoconnect; 1 tries left Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> Disabling autoconnect for connection ‘Wired connection 1’. Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> Disabling autoconnect for connection ‘Wired connection 1’; setting retry of 300. Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <warn> (eth1): Activation: failed for connection ‘Wired connection 1’ Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> (eth1): device state change: failed -> disconnected (reason ‘none’) [120 30 0] Apr 22 04:35:31 Fionnuisce NetworkManager[745]: <info> Device ‘eth1’ has no connection; scheduling activate_check in 0 seconds. </syslog>

<etc/network/interfaces>

This file describes the network interfaces available on your

system and how to activate them. For more information, see

interfaces(5).

The loopback network interface

auto lo iface lo inet loopback

The primary network interface

auto eth0 iface eth0 inet6 static address 2604:A880:0000:1010:0000:0000:05E9:A001 netmask 64 gateway 2604:A880:0000:1010:0000:0000:0000:0001 autoconf 0 dns-nameservers 8.8.8.8

2001:4860:4860::8844 2001:4860:4860::8888 8.8.8.8

iface eth0 inet static address xxx.xxx.x.xxx # droplet ip netmask 255.255.255.0 gateway xxx.xxx.x.xxx # droplet ip dns-nameservers 8.8.8.8 up ip addr add 10.13.0.5/16 dev eth0 <//etc/network/interfaces>

<DNS section of ‘/etc/openvpn/server.conf’> push “dhcp-option DNS localhost” push “dhcp-option DNS 8.8.8.8” push “dhcp-option DNS 8.8.4.4” </DNS section of ‘/etc/openvpn/server.conf’>

Justin,

It was probably done with permission, but did you know that someone by the name of John Capital submitted an exact duplicate of your work to ubtutorials.com, here:-

http://ubtutorials.com/tutorial/440/how-configure-bind-caching-or-forwarding-dns-server-ubuntu-1404

some 16 days after you uploaded this article? I checked the copy for attribution but found none, so i thought I’d mention it here. Please accept my apology for troubling you if this is old news and something you were aware of…

C

Thank you so much for the great article, I want to build a DNS server for about a 100-150 devices. What would you recommend should the system requirements be for the server? I am planning to build a DNS forwarding server as described in the article. Thank you!

Given that I’m setting up a DNS server on my droplet, are there any good ways to verify that only say, my devices are able to use it as a DNS server versus just anyone on the internet? Using an IP whitelist in this case isn’t effective given I can connect to many wifis via my laptop and my phone IP isn’t guaranteed.

Has anyone solved this problem?

Justin nice article. But I have one problem with the localhost address vs. a specified ip address for my BIND DNS server. I noticed in your DIG example it’s pointing to a specific ip address. Ex: SERVER: 192.0.2.1#53(192.0.2.1). This would be what you would expect for the setup.

How do I setup my server to point to my specified IP 172.16.y.z, instead of 127.0.0.1? I had already tried editing /etc/network/interfaces and /etc/bind/named.conf.options. I have Ubuntu Server LTS 14.04.1 and current installed updates. I’m running BIN9.9.5.

This comment has been deleted

Hi Justin thanks for this article, I have my DNS up and running on my Ubuntu machine. I do have one small problem I can’t seem to figure out. I am running my web server on the same computer as the DNS server, when I type in the domain name of my webpage from within the LAN it takes me to the router login page which is the gateway, it works fine from outside the LAN as the domain is registered with no-ip.com and the router forwards the request to the correct computer, the problem is only when within the LAN. if I put in 127.0.0.1, localhost or 192.168.1.20 I get the website if I put in the actual domain name I get this page can’t be found or the router login page, I must have something not setup correctly within the local settings of my new DNS, I hope you can help me sort this out.

Amazing! I can’t believe I got my own DNS server. Thank you!

The only problem is all queries are denied, the /var/log/syslog logs are like below:

MyServer named[24685]: client MyClientIP#7288 (client79.dropbox.com): query (cache) 'client79.dropbox.com/A/IN' denied
MyServer named[24685]: client MyClientIP#39385 (safebrowsing.google.com): query (cache) 'safebrowsing.google.com/A/IN' denied

Here is my config:

acl goodclients{
        MyClientIP; 
        localhost;
        localnets;
};

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };


        forwarders {
                8.8.8.8;
                8.8.4.4;
        };

        forward only;


        dnssec-enable yes;
        dnssec-validation yes;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};