Setting up a local DNS server with Unbound
Blacklists
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: "example.org" always_nxdomain
When a client asks the Unbound server where example.org
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 https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts $ su [password] # 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, 192.168.1.2
. 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 192.168.1.0/24
as the network.
Listing 6
local_names.conf
# /etc/unbound/unbound.conf.d/local_names.conf private-address: 192.168.1.0/24 local-zone: "mylan.dyn." static local-data: "gateway.mylan.dyn. IN A 192.168.1.1" local-data: "printer.mylan.dyn. IN A 192.168.1.2" local-data: "computer.mylan.dyn. IN A 192.168.1.3" local-data: "server.mylan.dyn. IN A 192.168.1.100" local-data-ptr: "192.168.1.1 gateway.mylan.dyn" local-data-ptr: "192.168.1.2 printer.mylan.dyn" local-data-ptr: "192.168.1.3 computer.mylan.dyn" local-data-ptr: "192.168.1.100 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, 192.168.1.2
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 192.168.1.2
?"
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 192.168.1.0/24
.
Listing 7
access_options.conf
# /etc/unbound/unbound.conf.d/access_options.conf access-control: "0.0.0.0/0" allow access-control: "127.0.0.0/8" allow access-control: "192.168.1.0/24" 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.
« Previous 1 2 3 4 Next »
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
-
The GNU Project Celebrates Its 40th Birthday
September 27 marks the 40th anniversary of the GNU Project, and it was celebrated with a hacker meeting in Biel/Bienne, Switzerland.
-
Linux Kernel Reducing Long-Term Support
LTS support for the Linux kernel is about to undergo some serious changes that will have a considerable impact on the future.
-
Fedora 39 Beta Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.