In part 1 of this article, I introduced you to Unbound, a great name resolution option for home labs and small network environments. We looked at what Unbound is, and we discussed how to install it. In this section, we'll work on the basic configuration of Unbound.
Basic configuration
First find and uncomment these two entries in unbound.conf
:
interface: 0.0.0.0
interface: ::0
Here, the 0
entry indicates that we'll be accepting DNS queries on all interfaces. If you have more than one interface in your server and need to manage where DNS is available, you would put the address of the interface here.
Next, we may want to control who is allowed to use our DNS server. We're going to limit access to the local subnets we're using. It's a good basic practice to be specific when we can:
Access-control: 127.0.0.0/8 allow # (allow queries from the local host)
access-control: 192.168.0.0/24 allow
access-control: 192.168.1.0/24 allow
We also want to add an exception for local, unsecured domains that aren't using DNSSEC validation:
domain-insecure: "forest.local"
Now I’m going to add my local authoritative BIND server as a stub-zone:
stub-zone:
name: "forest"
stub-addr: 192.168.0.220
stub-first: yes
If you want or need to use your Unbound server as an authoritative server, you can add a set of local-zone entries that look like this:
local-zone: “forest.local.” static
local-data: “jupiter.forest” IN A 192.168.0.200
local-data: “callisto.forest” IN A 192.168.0.222
These can be any type of record you need locally but note again that since these are all in the main configuration file, you might want to configure them as stub zones if you need authoritative records for more than a few hosts (see above).
If you were going to use this Unbound server as an authoritative DNS server, you would also want to make sure you have a root hints
file, which is the zone file for the root DNS servers.
Get the file from InterNIC. It is easiest to download it directly where you want it. My preference is usually to go ahead and put it where the other unbound related files are in /etc/unbound
:
wget https://www.internic.net/domain/named.root -O /etc/unbound/root.hints
Then add an entry to your unbound.conf
file to let Unbound know where the hints file goes:
# file to read root hints from.
root-hints: "/etc/unbound/root.hints"
Finally, we want to add at least one entry that tells Unbound where to forward requests to for recursion. Note that we could forward specific domains to specific DNS servers. In this example, I'm just going to forward everything out to a couple of DNS servers on the Internet:
forward-zone:
name: "."
forward-addr: 1.1.1.1
forward-addr: 8.8.8.8
Now, as a sanity check, we want to run the unbound-checkconf
command, which checks the syntax of our configuration file. We then resolve any errors we find.
[root@callisto ~]# unbound-checkconf
/etc/unbound/unbound_server.key: No such file or directory
[1584658345] unbound-checkconf[7553:0] fatal error: server-key-file: "/etc/unbound/unbound_server.key" does not exist
This error indicates that a key file which is generated at startup does not exist yet, so let's start Unbound and see what happens:
[root@callisto ~]# systemctl start unbound
With no fatal errors found, we can go ahead and make it start by default at server startup:
[root@callisto ~]# systemctl enable unbound
Created symlink from /etc/systemd/system/multi-user.target.wants/unbound.service to /usr/lib/systemd/system/unbound.service.
And you should be all set. Next, let's apply some of our DNS troubleshooting skills to see if it's working correctly.
First, we need to set our DNS resolver to use the new server:
[root@showme1 ~]# nmcli con mod ext ipv4.dns 192.168.0.222
[root@showme1 ~]# systemctl restart NetworkManager
[root@showme1 ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.0.222
[root@showme1 ~]#
Let's run dig
and see who we can see:
root@showme1 ~]# dig; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36486
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 508693 IN NS i.root-servers.net.
<snip>
Excellent! We are getting a response from the new server, and it's recursing us to the root domains. We don't see any errors so far. Now to check on a local host:
;; ANSWER SECTION:
jupiter.forest. 5190 IN A 192.168.0.200
Great! We are getting the A record from the authoritative server back, and the IP address is correct. What about external domains?
;; ANSWER SECTION:
redhat.com. 3600 IN A 209.132.183.105
Perfect! If we rerun it, will we get it from the cache?
;; ANSWER SECTION:
redhat.com. 3531 IN A 209.132.183.105
;; Query time: 0 msec
;; SERVER: 192.168.0.222#53(192.168.0.222)
Note the Query time of 0
seconds- this indicates that the answer lives on the caching server, so it wasn't necessary to go ask elsewhere. This is the main benefit of a local caching server, as we discussed earlier.
Wrapping up
While we did not discuss some of the more advanced features that are available in Unbound, one thing that deserves mention is DNSSEC. DNSSEC is becoming a standard for DNS servers, as it provides an additional layer of protection for DNS transactions. DNSSEC establishes a trust relationship that helps prevent things like spoofing and injection attacks. It's worth looking into a bit if you are using a DNS server that faces the public even though It's beyond the scope of this article.
[ Getting started with networking? Check out the Linux networking cheat sheet. ]
About the author
Glen Newell has been solving problems with technology for 20 years. As a Systems Engineer and administrator, he’s built and managed servers for Web Services, Healthcare, Finance, Education, and a wide variety of enterprise applications. He’s been working with and promoting open source technologies and methods for his entire career and loves to share what he learns and help people understand technology.
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit