Setting up a local DNS server with Unbound

Name Caddy

© Lead Image © Nataliia Natykach, 123RF.com

© Lead Image © Nataliia Natykach, 123RF.com

Article from Issue 227/2019
Author(s):

You don't have to be satisfied with your ISP's slow and cumbersome DNS server. Your own Unbound server could improve performance as well as security.

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.

Table 1

Publicly Available DNS Servers

Address

Operator

Stated Purpose

37.235.1.174

FreeDNS

Offering DNS services that bypass ISP tampering.

37.235.1.177

FreeDNS

Offering DNS services that bypass ISP tampering.

8.8.4.4

Google

Improving DNS query times.

8.8.8.8

Google

Improving DNS query times.

208.67.222.222

OpenDNS

Improving DNS query times.

208.67.220.220

OpenDNS

Improving DNS query times.

208.67.222.123

OpenDNS

Blacklisting adult content.

208.67.220.123

OpenDNS

Blacklisting adult content.

8.26.56.26

Comodo

Blacklisting malware and harmful domains.

8.20.247.20

Comodo

Blacklisting malware and harmful domains.

84.200.69.80

DNS.WATCH

Offering uncensored DNS services.

84.200.70.40

DNS.WATCH

Offering uncensored DNS services.

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.

Listing 1

unbound.conf

# /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.

Listing 2

name_solving.conf

# /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.

How Does DNSSEC Work?

The whole DNS system was designed in such a way that every connection was sent unencrypted over the network. Worse yet, there was no way to ensure that the traffic between DNS servers and DNS resolvers was not tampered with. For example, if you want to visit mybankwebsite.com and your web browser tries to resolve that domain, it is theoretically possible for some evil entity to intercept that DNS request and give you a fake response.

DNSSEC is an extension for the DNS protocol that lets DNS entries be cryptographically signed in such a way that the validity of a DNS response can be verified.

DNSSEC uses PKI (Public Key Infrastructure) in order to accomplish its goal. Each zone (including the Root Zone) has its public/private keypair. Keypairs are certified in a hierarchical way. The keypair of the .com zone has been signed with a key belonging to the administration of the root zone. The children zones directly below the .com zone are signed by the administrator of the .com zone, and so on. This builds what is called a chain of trust, and the public key that sits at the top of the hierarchy is known as the trust-anchor – it has no superior entity certifying its validity.

Most DNSSEC-aware resolvers use the root DNS public keying as their trust-anchor. When such a resolver needs to validate a DNS entry, it asks for the public keys of the administrator of its zone to the adequate authoritative server. If this public key needs validation, the resolver asks for the public key of its parent zone to an authoritative server of the parent zone, and this process continues until the trust-anchor is reached. Once the whole chain is fetched, it can be validated. After the validity of the chain is accepted, the public key at the end of the line may be used to check the authenticity of the cryptographic signature attached to the DNS entry.

DNSSEC has many drawbacks [3][4]. For one, it is argued that private keys related to popular TDLs (like .com or .net) are indirectly under the control of governments and are therefore compromised. Also, having to retrieve the public keys necessary for validating the chain increases the time the DNS query takes. Finally, many DNS zones have not enabled DNSSEC at all, which means that the domains under their management cannot have their validity verified.

This has lead to the creation of many alternatives, with different degrees of success and acceptance. DNS over TLS [5] and DNSCrypt [6] are two of the best known.

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.

Listing 3

dnssec_options.conf

# /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.

Listing 4

opennic_names.conf

# /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.

Listing 5

forwarders.conf

# /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.

Buy this article as PDF

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

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
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.

  • DNSSEC

    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

News