Setting up a local DNS server with Unbound


One big reason for running your own DNS server is to be able to blacklist sites you don't want the users of your LAN to visit. In a home environment, that's advertisers. In a small office, that might include time-wasting sites, such as social networks or digital sport journals. Your easiest option is to return bogus addresses or NXDOMAIN messages when asked about domains you don't want users to visit.

Something important to take into account is that DNS blacklisting is easy to set up but also very easy to bypass. Users in your LAN may try to configure their computers to use a different DNS server, use Tor, set up a VPN, or use a web proxy. A user can also bypass DNS if they already know the target IP address. A DNS blacklist thus works best when it is combined with other measures.

A simple way of blacklisting a domain is to add an entry like the following to your Unbound configuration:

local-zone: "" always_nxdomain

When a client asks the Unbound server where is, it will get an NXDOMAIN response.

Adding hosts manually to the configuration files can be tiresome. If you want to have good malware, phishing, and advertisement protection, getting an existing list of bad domains and adapting the list to Unbound is a good start. Many good lists of bad domains exist on the Internet. The StevenBlack blacklist [9] is very complete, so I will use it as a demonstration. The following commands will download the list and convert it to Unbound format:

$ curl -o hosts
$ su
# grep '^0\.0\.0\.0' hosts |
awk '{print "local-zone: \""$2"\"always_nxdomain"}' > /etc/unbound/unbound.conf.d/blacklist.conf

The Steven Black site has some tools for customizing the list, which are totally worth the time it takes to check them out.

Configuring Local Zones

Suppose you have a printer in your LAN. You can connect to that printer by using its known IP address, like, for example, However, wouldn't you rather give a human readable name to that printer?

Unbound is not an authoritative server, so it cannot manage a full zone with all its bells and whistles directly. However, it has horsepower enough for managing a small home LAN. Listing 6 shows an example configuration for a home LAN zone. It assumes that the LAN is using as the network.

Listing 6


# /etc/unbound/unbound.conf.d/local_names.conf
local-zone: "mylan.dyn." static
        local-data: "gateway.mylan.dyn. IN A"
        local-data: "printer.mylan.dyn. IN A"
        local-data: "computer.mylan.dyn. IN A"
        local-data: "server.mylan.dyn. IN A"
        local-data-ptr: " gateway.mylan.dyn"
        local-data-ptr: " printer.mylan.dyn"
        local-data-ptr: " computer.mylan.dyn"
        local-data-ptr: " server.mylan.dyn"

The private-address directive prevents addresses in your LAN from being returned for public Internet names. This step prevents DNS rebinding attacks [10].

The local-zone directive defines all domains under mylan.dyn as local. The static word means that the static entries defined in the configuration file are used as DNS entries. Each of the local-data entries assigns a name to an address. For example, would be assigned the name printer.mylan.dyn. If you queried the Unbound server for a name in the mylan.dyn zone that did not exist, it would be answered with a NXDOMAIN message. Alternatively, transparent could be used instead of static. A transparent local zone is one in which the server tries to resolve the name of a host by other means if it has no static entry for it in its configuration.

The local-data-ptr entries are optional and define reverse DNS information. Reverse DNS is, as the expression implies, the opposite of DNS. A reverse DNS query asks "What is the name of the host with the address"

Configuring Access

Listing 7 shows how to grant access to the Unbound server to hosts on your LAN and to the machine running the server. This example assumes that the LAN sits at

Listing 7


# /etc/unbound/unbound.conf.d/access_options.conf
access-control: "" allow
access-control: "" allow
access-control: "" allow

There are many good reasons for restricting access to your DNS server. The first one is that a DNS server may be used as part of a denial of service attack. A common technique is to send queries with spoofed IP addresses to exposed recursive DNS servers, which will send their responses to what they think is the computer that made the query in the first place. In practice, it means that an attacker can ask the recursive server for a DNS record using a fake IP, and the owner of the IP address that was faked will get the response. This means that an evil entity can force a recursive server to flood a victim with DNS responses and therefore use the server as a proxy for a denial of service attack. Another reason is that a local DNS server might contain sensitive DNS entries that are not intended to be known by outsiders. If you are using a local zone for naming local resources, such as printers, cameras, and NAS servers, it is better to have that information protected from outsiders.

In addition to the Unbound configuration presented here, it is a good idea to block access to your DNS server by using appropriate firewall rules. DNS servers listen for queries at port 53 and may support both UDP and TCP.

The access-control directives are self-explanatory.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Security Lessons: DNSSEC

    One of the largest holes in the Internet is finally plugged.


    Some Internet exploits target name resolution servers. DNSSEC uses cryptography to protect the name resolution service.

  • Security Lessons: DNS Security

    Kurt describes how to keep bad guys out of your network using a targeted filtering approach.

  • Bind 10 Test Drive

    Admins have waited all of five years for the 10th major release of the Bind name server, which appeared at the end of March this year. The latest release is a complete rewrite of the DNS server, with a modular design and new configuration tools, but is it ready for business?

  • NEWS

    In the news: Microsoft Edge Coming to Linux; Open Invention Network Backs Gnome Project Against Patent Troll; Fedora 31 Released; openSUSE OBS Can Now Build Windows WSL Images; Sudo Vulnerability; Hetzner Launches New Ryzen-Based Dedicated Root Servers; and IBM Joins the Mayflower Autonomous Ship Project.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More