Setting up a local DNS server with Unbound
Name Caddy
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 |
|
Improving DNS query times. |
8.8.8.8 |
|
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.
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).
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
(incl. VAT)
Buy Linux Magazine
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.
News
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.