DISCLAIMER: This guide will help you (and hopefully succeed) with setting up unbound with DNSSEC and replacing dnsmasq on an Ubiquity Edge Router. THIS GUIDE IS NOT COMPLETE WITH EVERY POSSIBLE CAVEAT for dnsmasq, unbound nor DNSSEC! But at the very least, it will get you close enough to debug your specific Router model, firmware and/or security requirement to an acceptable outcome. YOU MIGHT “BRICK” YOUR ROUTER in this process! So be sure you know how to perform a 30/30/30 reset on your Ubiquity Edge Router to restore factory settings back to a working state before you begin! See here for how to perform this operation: https://help.ui.com/hc/en-us/articles/205202620-EdgeRouter-Reset-to-Factory-Defaults
Awhile ago, we covered how to get DNSSEC working with Ubiquity Edge Routers in a previous post, found here: https://www.coolelectricity.com/2024/02/24/how-to-enable-dnssec-for-ubiquity-edgerouter-edgeos-stock-firmware/
The previous described method keeps using the from-the-factory-settings using dnsmasq. If you found this post because you were searching for a solution to your issues with DNS not resolving properly on an Ubiquity Edge-series router, you are not alone. There are numerous posts that have incomplete and sometimes incomprehensible details for some “custom solution” that others have cobbled together using the janky, dynamic and powerful CLI-tools in a terminal of Ubiquity router products. What prompted this update was the discovery of dnsmasq failing to resolve DNS names after losing a local DNS server that was set up as a primary DNS server, while assuming still having an Edge Router DNS Service enabled secondary DNS Server. With some surprise, it was realized that dnsmasq just straight up stopped working with the dnsmasq DNS Service, completely. No matter what was tried, rebooting the router, restarting the DNS service, tweaking the nameservers in /etc/resolv.conf, etc, nothing worked. While this is not a huge issue since there are a number of decent Public DNS Providers available, there are limits to privacy and configurability when relying on a 3rd party “free” service.
Through much trial and error, and a little bit of risk, there is a solution possible for replacing dnsmasq as your Ubiquity Edge Routers DNS Services with unbound, instead. BIND is another possible option, which is arguably better, but also potentially more complex. Since those familiar with great tools like pihole and dietpi may have more familiarity with unbound, and its not being used for a home lab router, the decision was made in favor of unbound. But not without some risks involved. Queue the disclaimer.
DISCLAIMER: If you are not familiar with how to perform commands in a terminal or shell prompt and troubleshoot issues, this solution is not for you. If you are not familiar with how to do a factory reset on a router, specifically Ubiquity Edge-series Routers, this solution is not for you. If you are not familiar with editing .conf files and using the ‘find’ function from a shell in Linux, this solution is not for you. If you want a smooth and easy way to get DNSSEC enabled on your Ubiquity Edge-series Router, you may be better off learning how to do a factory reset of your router FIRST, before creating a situation where you cannot recover from a misconfiguration of a router than has very difficult to understand limitations and powers.
Ubiquity makes great products, but they are higher priced than comparable or even superior spec brands. But Ubiquity’s powerful and somewhat simplistic design for its UI and “config tree” configuration make it compelling for power users. But what do power users do? Tweak things. And one of the super powers of the Ubiquity Edge-series routers is the ability to enable Debian Linux repositories to install additional features.
We will assume you are working with the much more recent EdgeOS version 2.+ since there have been a number of “hacks” and known vulnerabilities discovered for SSL/TLS and SSH over the years. If you haven’t updated to EdgeOS v2, there is still a chance this could work for you, but you will be on your own if there are any nuances between these major versions. Here is a link to explore for how to enable the Debian Stretch package repositories for both v1 and v2 EdgeOS, but we will cover v2 below.
Taken verbatim from the Ubiquity Support page:
CLI: Access the EdgeRouter Command Line Interface.
1. Enter configuration mode.
configure
2. Add a Debian repository.
set system package repository stretch components 'main contrib non-free'
set system package repository stretch distribution stretch
set system package repository stretch url http://archive.debian.org/debian
3. Commit the changes and save the configuration.
commit ; save
4. Update the local cache.
sudo apt-get update
WARNING: Do not use the apt-get upgrade command as it can break the customized Debian packages used in EdgeOS.
5. Search for the package you wish to install. In this example, the dnsutils utility is added to EdgeOS.Copy
sudo apt-cache search dnsutils
6. Install the package.
sudo apt-get install dnsutils
7. Test out the newly installed package
dig coolelectricity.com +dnssec
Notice that you can now use the dig command (provided by the now installed dnsutils package from the the now added Debian Stretch repository. Note that by adding the +dnssec parameter, you can validate if DNSSEC is being used by the domain name.
8. EXTREMELY IMPORTANT NOTE: Be very sure to take heed to that WARNING message, about NEVER using the “apt up
grade” command after adding a new repository to an Ubiquity Edge Router! If you are a regular Ubuntu, Mint or other Debian-based Linux Distro user, it’s hard to break the habit of doing apt-get update AND upgrade at the same time. If you do this by accident, there is a very high change that you will need to do a 30/30/30 factory reset of your router to restore its function (but YMMV).
Now that the Debian Stretch repo is installed, enabled and working, with dnsutils installed, we can also now use nslookup and dig to help us test (note that Ubiquity EdgeOS does have a variant of nslookup already by default but its called “host”: host coolelectricity.com 127.0.0.1 )
#Confirm that the in-router DNS service is working correctly:
nslookup coolelectricity.com 127.0.0.1
# or
host coolelectricity.com 127.0.0.1
You can also “see” if the unbound service running on the Ubiquity Edge Router is working with DNSSEC or not by the following test:
dig coolelectricity.com 127.0.0.1 +dnssec
Chances are slim that you will get the proper DNSSEC response, because there is not any DNSSEC configuration, unless it was previously installed (or you followed our older guide for DNSSEC with dnsmasq).
10. Now its time to install, enable and start the unbound service, but also stop and disable the dnsmasq service, so they do not conflict (both use port 53):
#install unbound
sudo apt-get install unbound
#stop the dnsmasq service
sudo systemctl stop dnsmasq
#start the unbound service
sudo systemctl start unbound
#check the status of the unbound service to making sure its Active
sudo systemctl status unbound
#check the status of the dnsmasq service to making sure its NOT active
sudo systemctl status unbound
Now, assuming the unbound service is running, try to test that DNS resolution is working as expected by running the following commands that we previously tested with:
#Confirm that the in-router DNS service is working correctly with the newly installed unbound service:
nslookup coolelectricity.com 127.0.0.1
# or
host coolelectricity.com 127.0.0.1
11. Now the next part is where things start to get messy.
Optional consideration: There are a number of tutorials online that show a variety of ways to use the “anchors” and “hints” with the Unbound DNS service. What is “supposed to work out of the box”, is the installation, enabled-on-boot and starting of a soon-to-be-added service called dnssec-triggerd (note the ‘d’ at the end).
#install dnssec-triggerd
sudo apt-get install unbound dnssec-triggerd -y
#start the dnssec-triggerd service
sudo systemctl start dnssec-triggerd
#Ensure the dnssec-triggerd service is running
sudo systemctl status dnssec-triggerd
# Restart the unbound service so that it MIGHT inherit the newly configured dnssec-triggerd settings
HIGHLY RECOMMENDED ARTICLE FOR RESOLVING YOUR UNIQUE CONFIGURATION ISSUES WITH UNBOUND AND/OR DNSSEC-TRIGGERD: https://www.sidn.nl/en/modern-internet-standards/dnssec-validation-using-unbound-and-dnssec-trigger
The above article goes into some extensive, gory details for how to install both Unbound and dnssec-triggerd on ANY system. The intent of this particular article is for only Ubiquity Edge Routers capable of leveraging Debian Stretch repository packages.
FWIW, the following configuration “works on our machine”:
Instead of adding all of our configuration by using the “default” location for the unbound config file at /etc/unbound/unbound.conf, we keep all of the needed unbound config in a single “referenced directory”, like below:
~$ cat /etc/unbound/unbound.conf
# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include: "/etc/unbound/unbound.conf.d/*.conf"
Note that any file with a *.conf file extension in the subdirectory /etc/unbound/unbound.conf.d/* with have its configuration parameters “read” by the unbound service when it starts.
ubnt@ubiquityedgerouter:~$ cat /etc/unbound/unbound.conf.d/unbound.conf
server:
# disable user privilege protection - # use "" (empty) if no "unbound" user exists:
username: ""
# disable chroot
chroot: ""
qname-minimisation: yes
# allow ALL interfaces (and therefor all ports) of the device to use Unbound
interface: 0.0.0.0
# only allow your local network to use the Unbound service (change to your CIDR)
## use 192.168.0.0/16 for MOST home systems/default router/switch CIDRs
access-control: 192.168.0.0/16 allow
# Some security/privacy options:
## see more: https://medium.com/@steffinstanly/unbound-dns-blocking-3567986a5735
hide-identity: yes
hide-version: yes
# We comment out 'use-syslog' to prevent logs filling disk, unless needed
#use-syslog: yes
# other optional settings (some are disabled with #[commented lines])
prefetch: yes
cache-max-ttl: 14400
cache-min-ttl: 900
#rrset-roundrobin: yes
# VERY IMPORTANT SETTINGS NEEDED - CONFIGURE TO YOU NEEDS
do-tcp: yes
do-udp: yes
do-ip4: yes
do-ip6: no
# See here for a (very lengthy) list of ALL options available for
## the unbound service and their descriptions:
## https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.htmlNext, we have the following file, in the same directory (note the spelling of qname-minimisation.conf is using an ‘s’ and not a ‘z’!):
ubnt@ubiquityedgerouter:~$ cat /etc/unbound/unbound.conf.d/qname-minimisation.conf
server:
# Send minimum amount of information to upstream servers to enhance
# privacy. Only sends minimum required labels of the QNAME and sets
# QTYPE to NS when possible.
# See RFC 7816 "DNS Query Name Minimisation to Improve Privacy" for
# details.
qname-minimisation: yesLastly, and again in the same directory, we have the file ‘root-auto-trust-anchor-file.conf’ with the below contents.
ubnt@ubiquityedgerouter:~$ cat /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf
server:
# The following line will configure unbound to perform cryptographic
# DNSSEC validation using the root trust anchor.
auto-trust-anchor-file: "/var/lib/unbound/root.key"
IMPORTANT NOTE ABOUT TRUST ANCHORS:
While you do not technically need to add and install the dnssec-triggerd service, it SHOULD make this process considerably easier by installing those trust anchors in the proper location, as well as configure the unbound service to use them. You will want to verify that you have the correct file and contents for /var/lib/unbound/root.key in the configured file location by using:
ubnt@ubiquityedgerouter:~$ cat /var/lib/unbound/root.key
The above command should result in something similar to the following (as of the time of this writing in Q4 of 2024):
ubnt@ubiquityedgerouter:~$ cat /var/lib/unbound/root.key
;;last_queried: 1731000000 ;;Fri Nov 1 00:00:00 2024
;;last_success: 1731000000 ;;Fri Nov 1 00:00:00 2024
;;next_probe_time: 1731000000 ;;Fri Nov 1 00:00:00 2024
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
. 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNRO
xVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDW
fdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=173000000
3 ;;Fri Nov 1 00:00:00 2024It’s a bit of a rabbit hole, but note that these “DNSSEC Root Keys” tend to change at least once about every 7 or 8 years, so using the dnssec-triggerd service can help with avoiding configuring the keys “manually”. See here for all the deep dive details about the expected key change coming in 2025: https://www.iana.org/dnssec/files
Now if you haven’t brought everything together yet for your new configuration to work as expected (for the n00bZ), let’s do that now.
# Make sure dnsmasq is not running!
sudo systemctl stop dnsmasq
sudo systemctl status dnsmasq #should be inactive...
# Make sure dnssec-triggerd is running
sudo systemctl restart dnssec-triggerd
sudo systemctl status dnsmasq #should be Active!
# Make sure unbound is running
sudo systemctl restart unbound
sudo systemctl status unbound #should be Active!
# Make you have 127.0.0.1 as your 'topmost' DNS Server on the Ubiquity Edge Router
ubnt@ubiquityedgerouter:~$ cat /etc/resolv.conf
# Generated by dnssec-trigger-script
nameserver 127.0.0.1
# test that you have DNSSEC working by using dig .... +dnssec
dig coolelectricity.com 127.0.0.1 +dnssec
# Take note of the "AUTHORITY SECTION" as it should show RRSIG information
#If all is working as expected, make these new settings persist on reboots:
sudo systemctl disable dnsmasq #disabled dnsmasq, so it does NOT start at boot
sudo systemctl enable unbound #enabled unbound, so it DOES start at boot
## Optionally disable dnssec-triggerd service since the service is rarely needed
sudo systemctl stop dnssec-triggerd # only needed once every 7+ years? (on average)
sudo systemctl disable dnssec-triggerd # instead, manually trigger the service start
# Final test of DNSSEC before rebooting Ubiquity Edge Router to ensure persistence
dig coolelectricity.com 127.0.0.1 +dnssec
# If RRSIG's show encryption keys + success of the query, you should be good!
sudo reboot
# Cross your fingers and wait for the network to come back up!Conclusion
As stated in the beginning of this guide, there are a lot of other nuances and caveats to both unbound and DNNSSEC related to the trust anchors and network security requirements you have, but these instructions and the included related links should at least provide a common sense path for you to get unbound with DNSSEC working on your Ubiquity Edge Router!