When you turn your home computer on, launch a web browser, and instruct it to visit the linux-magazine.com website, your computer sends a DNS query, asking for the IP address associated with the name linux-magazine.com. For many users, this query is sent to a DNS server provided by the user's Internet Service Provider (ISP).

Using your ISP's DNS server is an easy and low-stress option, but in many situations, it also has some disadvantages. The most popular reason why some users prefer a non-default DNS server is performance. Simply put: some servers have lower latency and faster query times than others. If your ISP's DNS servers are slow, switching to faster servers will lead to noticeable improvement in your web browsing experience.

Another reason for switching to a different server is to avoid (or enforce) soft censorship. For instance, a school administrator might wish to prevent students from accessing social networking sites such as facebook.com during the school day. The easiest way to prevent a user from reaching a website is to instruct the DNS server to return a bogus address or to return an NXDOMAIN message, which means the server doesn't think the domain exists. Another option is for the server to return the address of a webpage that displays a message such as "No Social Networking Allowed Here."

Many DNS providers offer anti-advertisement, anti-malware, and anti-phishing protection in such a way that, if your browser tries to resolve the address of some service known to serve advertisements or harmful code, it will be redirected to a bogus address or a site with a warning. Parental controls that filter sites deemed unsafe for kids are also offered by some DNS providers. See Table 1 for a list of some third-party DNS providers.

A third-party provider could help you with performance and parental control, but if you want to customize the DNS environment, you will need to set up your own server.

Running your own DNS server in your own premises gives you a lot of flexibility. You could also get a performance boost. Imagine that there are four family members in a home LAN, and two are browsing the Internet at the same time. One person visits linux-magazine.com. Then a different person, sitting at a different computer, visits the same site. If this LAN has a local DNS server, the server that resolves the address for the first user could cache the address. When the second user visits the same site, the server could provide the address from the cache without having to pull the information from outside the network.

Running your own DNS servers allows you to have custom DNS entries. You can create your own blacklists (that block advertisements, for example). You can also assign names to local resources, such as your printer, your NAS, or your IP cameras.

Another benefit of a local DNS server is that it lets you take advantage of DNSSEC [1], which still has not been implemented by many ISPs. DNSSEC is a security overlay that protects users from having DNS traffic altered by malicious actors. Its actual usefulness is disputed, but some users prefer the protection of DNSSEC. This article describes how to set up your own DNSSEC-aware DNS configuration using the Unbound DNS server.

Enter Unbound

BIND is the undisputed king of free and open source DNS servers. The BIND DNS server is feature rich, well documented, and available on most distributions. On the other hand, BIND is too heavy for most small LANs, and it has some significant security concerns.

Unbound is a non-authoritative, recursive DNS server, with support for DNSSEC validation (see the box entitled "Authoritative Servers and Recursive Servers.") It is included in the default installation of the OpenBSD operating system and is available on the repositories of most serious Linux distributions. It is easy to configure and quick to set up.

Authoritative Servers and Recursive Servers

Authoritative DNS servers [2] are servers designed to answer DNS queries pertaining to a specific DNS zone. A DNS zone is a distinct portion of a DNS hierarchy (usually the global Internet one) that has been placed under the administration of a particular entity. This is to say, it is the sort of server Verisign uses to administrate the .com TDL and ensure that sites that use the .com zone can be found on the Internet. Definitively not the sort of DNS server you use in your home LAN.

There are 13 very special authoritative DNS servers, known as the root DNS servers. A root DNS server is a name server located in the root DNS zone, which is the highest zone in the DNS hierarchy (Figure 1). The root DNS servers are authoritative for the whole DNS space.

Figure 1: DNS is a hierarchical system. Zone administrators delegate parts of their zones to other administrators below them in the hierarchy.

In theory, the whole Internet could be managed by authoritative servers alone. A DNS resolver that has to depend exclusively on authoritative servers would first contact one of the root DNS servers. If the resolver were trying to solve, as an example, www.example.org, the root DNS server contacted would answer "I don't know the address of www.example.org, but this other authoritative server does" and guide it to some server responsible of the .org TDL. When the resolver asked this new server for an answer, it would either get a result or be told to look for an answer at some other authoritative server placed below in the DNS hierarchy (Figure 2).

Figure 2: An iterative DNS query against authoritative DNS servers.

If every resolver and DNS server worked like that, the Internet would collapse under the traffic load, since a very small number of root servers and authoritative servers for TDL zones would have to answer so many queries.

The sort of DNS server ISPs provide to their customers is usually a recursive caching server. Recursive servers are designed to answer DNS queries without overloading the root servers. When a DNS resolver asks a recursive server "where is www.example.org?", the server will ask other DNS servers on behalf of the resolver, and return an already valid and final answer. Since most recursive servers also have big caches, they may be able to extract an answer for the DNS resolver from their caches without having to send additional queries to other DNS servers.

Usually, local system administrators install their DNS servers on machines that run 24 hours a day. In a home environment, any machine that is continuously running torrent software, or a web proxy, or any infrastructure service, will be a perfect candidate. A small Single Board Computer (SBC) such as a Raspberry Pi will also do the trick, if you don't want to assign the task to a full featured computer.

In Devuan, you can install Unbound using the apt-get utility:

# apt-get install unbound

Services in Devuan are started upon installation by default. You might want to stop it right away and begin with the configuration:

# /etc/init.d/unbound stop

One of your first steps should be to install a root hints file. This file contains the location of the root DNS servers of the Internet. Unbound itself comes with a hardcoded set of root servers, but it is always a good idea to provide it with an up-to-date set, just in case. The hardcoded set is prone to become outdated.

You can obtain an updated list as follows:

# cd /etc/unbound
# curl -Lo /etc/unbound/root.hints https://www.internic.net/domain/named.cache

This file should be updated periodically. You can execute the update through a cron job or manually. A 6-month interval is adequate for home purposes.

Be careful which root list you use! If your list contains malicious servers, you will be vulnerable to certain attacks, like having DNS queries answered with malicious results.

Listing 1 shows a possible configuration file for Unbound. The /etc/unbound/unbound.conf file loads different directives from files located in /etc/unbound/unbound.conf.d.

# /etc/unbound/unbound.conf
# The include directive loads
# configuration parameters
# from the indicated files.
server:
include: /etc/unbound/unbound.conf.d/access_options.conf
include: /etc/unbound/unbound.conf.d/name_solving.conf
include: /etc/unbound/unbound.conf.d/privacy_options.conf
include: /etc/unbound/unbound.conf.d/cache_options.conf
include: /etc/unbound/unbound.conf.d/dnssec_options.conf
include: /etc/unbound/unbound.conf.d/blacklist.conf
include: /etc/unbound/unbound.conf.d/local_names.conf
include: /etc/unbound/unbound.conf.d/opennic_names.conf
include: /etc/unbound/unbound.conf.d/forwarders.conf
remote-control:
        #Disable remote control which we don't intend to use.
        control-enable: no

Listing 2 shows an example of how to configure Unbound to use the root hints file. The root-hints parameter tells the server the name of the root hints file.

# /etc/unbound/unbound.conf.d/name_solving.conf
root-hints: /etc/unbound/root.hints

Enabling DNSSEC

DNSSEC is a protocol designed to prevent man-in-the-middle attacks against DNS queries that could result in the DNS resolver getting a maliciously crafted DNS response. See the box "How Does DNSSEC Work?" for more information.

The DNSSEC trust anchor can be retrieved and initialized by issuing the following command:

# unbound-anchor -a "/var/lib/unbound/root.key"
# chown unbound:unbound "/var/lib/unbound/root.key"
# chmod 500 "/var/lib/unbound/root.key"

Listing 3 displays an example configuration that enables DNSSEC validation. The auto-trust-anchor-file parameter points at the root key of the DNSSEC trust anchor. This key is stored in a file. As long as the user running the Unbound server has read and write permissions over the trust anchor file and the folder that contains it, Unbound itself will be able to keep the trust anchor updated automatically. The domain-insecure parameters in Listing 3 disables DNSSEC verification for the unofficial DNS zones .dyn and .geek.

# /etc/unbound/unbound.conf.d/dnssec_options.conf
auto-trust-anchor-file: "/var/lib/unbound/root.key"
domain-insecure: "dyn."
domain-insecure: "geek."

Using Multiple Forwarders

By default, your Unbound server will try to resolve DNS entries by asking the root DNS servers for an answer. This is OK, but sometime you want to adopt a different approach.

You may want to have a list of recursive DNS servers to send DNS queries to, like, for example, the ones provided by your ISP. You can set forward zones, which designate DNS zones that will have queries related to them forwarded to servers you designate.

Suppose that, for any reason, you want all your queries for domains in the .geek zone sent to an Opennic server instead of to the root DNS servers. The example configuration at Listing 4 ensures that queries for domains under the .geek and .dyn extraofficial TDLs are forwarded to a DNS server of the Opennic Project.

# /etc/unbound/unbound.conf.d/opennic_names.conf
forward-zone:
        name: "dyn."
        forward-addr: 193.183.98.66     #opennic
        forward-addr: 87.98.175.85    #opennic
        forward-addr: 5.135.183.146   #opennic
        forward-addr: 51.254.25.115     #opennic
forward-zone:
        name: "geek."
        forward-addr: 193.183.98.66     #opennic
        forward-addr: 87.98.175.85   #opennic
        forward-addr: 5.135.183.146   #opennic
        forward-addr: 51.254.25.115     #opennic

Why is this feature useful? For two main reasons. The first one is that you might want to connect to an alternative, unofficial DNS infrastructure, such as the Opennic Project [7], which carries unofficial TDLs that are not recognized by the IANA.

The second reason is that you may not want to use the root servers at all. In fact, end users are not expected to use them and depend on recursive servers instead. The example at Listing 5 instructs Unbound to use two recursive DNS servers from DNS.WATCH [8] when attempting to resolve any domain name located under the root zone, which, in practice, means every domain.

# /etc/unbound/unbound.conf.d/forwarders.conf
forward-zone:
        name: "."
        forward-addr: 84.200.69.80      #DNS.WATCH
        forward-addr: 84.200.70.40      #DNS.WATCH
        forward-addr: 51.254.25.115     #opennic

In any case, remember that, as long as DNSSEC is enabled, DNSSEC verification will be attempted in any DNS query Unbound initiates, including queries that use forward servers. If you select forward servers that don't support DNSSEC, the queries will fail because verification is not possible, and your whole name resolution system will become inoperative. As demonstrated in Listing 3, you can disable DNSSEC validation for domains and zones that are problematic.