|
| 1 | +# Unbound |
| 2 | + |
| 3 | + |
| 4 | + |
| 5 | +## Introduction |
| 6 | + |
| 7 | +[Unbound](https://nlnetlabs.nl/projects/unbound/about/) is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. |
| 8 | + |
| 9 | +### What is a recursive DNS server? |
| 10 | + |
| 11 | +The first distinction we have to be aware of is whether a DNS server is authoritative or not. |
| 12 | + |
| 13 | +If I'm the authoritative server for, e.g., ```akkupy.me```, then I know which IP is the correct answer for a query. Recursive name servers, in contrast, resolve any query they receive by consulting the servers authoritative for this query by traversing the domain. |
| 14 | + |
| 15 | +Example: We want to resolve ```akkupy.me```. On behalf of the client, the recursive DNS server will traverse the path of the domain across the Internet to deliver the answer to the question. |
| 16 | + |
| 17 | + |
| 18 | +## Setting up Pi-hole as a recursive DNS server solution¶ |
| 19 | + |
| 20 | +We will use ```unbound```, a secure open-source recursive DNS server primarily developed by NLnet Labs, VeriSign Inc., Nominet, and Kirei. The first thing you need to do is to install the recursive DNS resolver: |
| 21 | + |
| 22 | +``` |
| 23 | +sudo apt install unbound |
| 24 | +``` |
| 25 | + |
| 26 | +If you are installing unbound from a package manager, it should install the ```root.hints``` file automatically with the dependency ```dns-root-data```. The root hints will then be automatically updated by your package manager. |
| 27 | + |
| 28 | +Optional: Download the current root hints file (the list of primary root servers which are serving the domain "." - the root domain). Update it roughly every six months. Note that this file changes infrequently. This is only necessary if you are not installing unbound from a package manager. If you do this optional step, you will need to uncomment the ```root-hints:``` configuration line in the suggested config file. |
| 29 | + |
| 30 | +``` |
| 31 | +wget https://www.internic.net/domain/named.root -qO- | sudo tee /var/lib/unbound/root.hints |
| 32 | +``` |
| 33 | +### Configure ```unbound``` |
| 34 | + |
| 35 | +Highlights: |
| 36 | + |
| 37 | + * Listen only for queries from the local Pi-hole installation (on port 5335) |
| 38 | + * Listen for both UDP and TCP requests |
| 39 | + * Verify DNSSEC signatures, discarding BOGUS domains |
| 40 | + * Apply a few security and privacy tricks |
| 41 | + |
| 42 | + ```/etc/unbound/unbound.conf.d/pi-hole.conf```: |
| 43 | + |
| 44 | + ``` |
| 45 | + server: |
| 46 | + # If no logfile is specified, syslog is used |
| 47 | + # logfile: "/var/log/unbound/unbound.log" |
| 48 | + verbosity: 0 |
| 49 | +
|
| 50 | + interface: 127.0.0.1 |
| 51 | + port: 5335 |
| 52 | + do-ip4: yes |
| 53 | + do-udp: yes |
| 54 | + do-tcp: yes |
| 55 | +
|
| 56 | + # May be set to yes if you have IPv6 connectivity |
| 57 | + do-ip6: no |
| 58 | +
|
| 59 | + # You want to leave this to no unless you have *native* IPv6. With 6to4 and |
| 60 | + # Terredo tunnels your web browser should favor IPv4 for the same reasons |
| 61 | + prefer-ip6: no |
| 62 | +
|
| 63 | + # Use this only when you downloaded the list of primary root servers! |
| 64 | + # If you use the default dns-root-data package, unbound will find it automatically |
| 65 | + #root-hints: "/var/lib/unbound/root.hints" |
| 66 | +
|
| 67 | + # Trust glue only if it is within the server's authority |
| 68 | + harden-glue: yes |
| 69 | +
|
| 70 | + # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS |
| 71 | + harden-dnssec-stripped: yes |
| 72 | +
|
| 73 | + # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes |
| 74 | + # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details |
| 75 | + use-caps-for-id: no |
| 76 | +
|
| 77 | + # Reduce EDNS reassembly buffer size. |
| 78 | + # IP fragmentation is unreliable on the Internet today, and can cause |
| 79 | + # transmission failures when large DNS messages are sent via UDP. Even |
| 80 | + # when fragmentation does work, it may not be secure; it is theoretically |
| 81 | + # possible to spoof parts of a fragmented DNS message, without easy |
| 82 | + # detection at the receiving end. Recently, there was an excellent study |
| 83 | + # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<< |
| 84 | + # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/) |
| 85 | + # in collaboration with NLnet Labs explored DNS using real world data from the |
| 86 | + # the RIPE Atlas probes and the researchers suggested different values for |
| 87 | + # IPv4 and IPv6 and in different scenarios. They advise that servers should |
| 88 | + # be configured to limit DNS messages sent over UDP to a size that will not |
| 89 | + # trigger fragmentation on typical network links. DNS servers can switch |
| 90 | + # from UDP to TCP when a DNS response is too big to fit in this limited |
| 91 | + # buffer size. This value has also been suggested in DNS Flag Day 2020. |
| 92 | + edns-buffer-size: 1232 |
| 93 | +
|
| 94 | + # Perform prefetching of close to expired message cache entries |
| 95 | + # This only applies to domains that have been frequently queried |
| 96 | + prefetch: yes |
| 97 | +
|
| 98 | + # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1. |
| 99 | + num-threads: 1 |
| 100 | +
|
| 101 | + # Ensure kernel buffer is large enough to not lose messages in traffic spikes |
| 102 | + so-rcvbuf: 1m |
| 103 | +
|
| 104 | + # Ensure privacy of local IP ranges |
| 105 | + private-address: 192.168.0.0/16 |
| 106 | + private-address: 169.254.0.0/16 |
| 107 | + private-address: 172.16.0.0/12 |
| 108 | + private-address: 10.0.0.0/8 |
| 109 | + private-address: fd00::/8 |
| 110 | + private-address: fe80::/10 |
| 111 | + ``` |
| 112 | + |
| 113 | + Start your local recursive server and test that it's operational: |
| 114 | + |
| 115 | + ``` |
| 116 | + sudo service unbound restart |
| 117 | +dig pi-hole.net @127.0.0.1 -p 5335 |
| 118 | + ``` |
| 119 | + |
| 120 | + The first query may be quite slow, but subsequent queries, also to other domains under the same TLD, should be fairly quick. |
| 121 | + |
| 122 | + You should also consider adding |
| 123 | + |
| 124 | + ``` |
| 125 | + edns-packet-max=1232 |
| 126 | + ``` |
| 127 | +to a config file like ```/etc/dnsmasq.d/99-edns.conf``` to signal FTL to adhere to this limit. |
| 128 | + |
| 129 | +### Test validation |
| 130 | + |
| 131 | +You can test DNSSEC validation using |
| 132 | + |
| 133 | +``` |
| 134 | +dig fail01.dnssec.works @127.0.0.1 -p 5335 |
| 135 | +dig dnssec.works @127.0.0.1 -p 5335 |
| 136 | +``` |
| 137 | + |
| 138 | +The first command should give a status report of ```SERVFAIL``` and no IP address. The second should give ```NOERROR``` plus an IP address. |
| 139 | + |
| 140 | +### Configure ```Pi-hole``` |
| 141 | + |
| 142 | +Finally, configure Pi-hole to use your recursive DNS server by specifying ```127.0.0.1#5335``` as the Custom DNS (IPv4): |
| 143 | + |
| 144 | + |
| 145 | + |
| 146 | +(don't forget to hit Return or click on ```Save```) |
| 147 | + |
| 148 | +### Disable ```resolvconf.conf``` entry for ```unbound``` (Required for Debian Bullseye+ releases) |
| 149 | + |
| 150 | +Debian Bullseye+ releases auto-install a package called ```openresolv``` with a certain configuration that will cause unexpected behaviour for pihole and unbound. |
| 151 | + |
| 152 | + The effect is that the ```unbound-resolvconf.service``` instructs ```resolvconf``` to write ```unbound```'s own DNS service at ```nameserver 127.0.0.1``` , but without the 5335 port, into the file ```/etc/resolv.conf```. |
| 153 | + |
| 154 | + That ```/etc/resolv.conf``` file is used by local services/processes to determine DNS servers configured. You need to edit the configuration file and disable the service to work-around the misconfiguration. |
| 155 | + |
| 156 | + #### Step 1 - Disable the Service |
| 157 | + |
| 158 | + To check if this service is enabled for your distribution, run below one. It will show either ```active``` or ```inactive``` or it might not even be installed resulting in a ```could not be found``` message: |
| 159 | + |
| 160 | + ``` |
| 161 | + systemctl is-active unbound-resolvconf.service |
| 162 | + ``` |
| 163 | + |
| 164 | + To disable the service, run the statement below: |
| 165 | + |
| 166 | + ``` |
| 167 | + sudo systemctl disable --now unbound-resolvconf.service |
| 168 | + ``` |
| 169 | + |
| 170 | + #### Step 2 - Disable the file resolvconf_resolvers.conf |
| 171 | + |
| 172 | + Disable the file resolvconf_resolvers.conf from being generated when resolvconf is invoked elsewhere. |
| 173 | + |
| 174 | + ``` |
| 175 | + sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf |
| 176 | + sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf |
| 177 | + ``` |
| 178 | + Restart ```unbound```. |
| 179 | + |
| 180 | + ``` |
| 181 | + sudo service unbound restart |
| 182 | + ``` |
| 183 | + |
| 184 | +### Add logging to unbound |
| 185 | + |
| 186 | +> **WARNING :** |
| 187 | +> It's not recommended to increase verbosity for daily use, as unbound logs a lot. But it might be helpful for debugging purposes. |
| 188 | +
|
| 189 | +There are five levels of verbosity |
| 190 | + |
| 191 | +``` |
| 192 | +Level 0 means no verbosity, only errors |
| 193 | +Level 1 gives operational information |
| 194 | +Level 2 gives detailed operational information |
| 195 | +Level 3 gives query level information |
| 196 | +Level 4 gives algorithm level information |
| 197 | +Level 5 logs client identification for cache misses |
| 198 | +``` |
| 199 | + |
| 200 | +First, specify the log file, human-readable timestamps and the verbosity level in the ```server``` part of ```/etc/unbound/unbound.conf.d/pi-hole.conf```: |
| 201 | + |
| 202 | +``` |
| 203 | +server: |
| 204 | + # If no logfile is specified, syslog is used |
| 205 | + logfile: "/var/log/unbound/unbound.log" |
| 206 | + log-time-ascii: yes |
| 207 | + verbosity: 1 |
| 208 | +``` |
| 209 | + |
| 210 | +Second, create log dir and file, set permissions: |
| 211 | + |
| 212 | +``` |
| 213 | +sudo mkdir -p /var/log/unbound |
| 214 | +sudo touch /var/log/unbound/unbound.log |
| 215 | +sudo chown unbound /var/log/unbound/unbound.log |
| 216 | +``` |
| 217 | + |
| 218 | +On modern Debian/Ubuntu-based Linux systems, you'll also have to add an AppArmor exception for this new file so ```unbound``` can write into it. |
| 219 | + |
| 220 | +Create (or edit if existing) the file ```/etc/apparmor.d/local/usr.sbin.unbound``` and append |
| 221 | + |
| 222 | +``` |
| 223 | +/var/log/unbound/unbound.log rw, |
| 224 | +``` |
| 225 | + |
| 226 | +to the end (make sure this value is the same as above). Then reload AppArmor using |
| 227 | + |
| 228 | +``` |
| 229 | +sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.unbound |
| 230 | +sudo service unbound restart |
| 231 | +``` |
| 232 | + |
| 233 | +Lastly, restart ```unbound```: |
| 234 | + |
| 235 | +``` |
| 236 | +sudo service unbound restart |
| 237 | +``` |
| 238 | + |
| 239 | +### Uninstall ```unbound``` |
| 240 | + |
| 241 | +To remove ```unbound``` from your system run |
| 242 | + |
| 243 | +``` |
| 244 | +sudo apt remove unbound |
| 245 | +``` |
| 246 | +Make sure to switch to another upstream DNS server for ```Pi-hole```. |
| 247 | + |
0 commit comments