Is Unbound Working Properly?

Required Information

  • DietPi version | G_DIETPI_VERSION_CORE=8
    G_DIETPI_VERSION_SUB=22
    G_DIETPI_VERSION_RC=3
    G_GITBRANCH=‘master’
    G_GITOWNER=‘MichaIng’

  • Distro version | bookworm 0

  • Kernel version | Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

  • Architecture | arm64

  • SBC model | RPi Zero 2 W (aarch64)

  • Power supply used | 5V

  • SD card used | SanDisk ultra

Additional Information (if applicable)

  • Software title | pihole+upbound
  • Was the software title installed freshly or updated/migrated? | fresh install using dietpi-software
    (I have shortened the logs below to remove the number of links limit.)
    Steps to reproduce
  1. dig sigfail...@127.0.0.1 -p 5335
    ;; Got answer: status: SERVFAIL, id: 19779
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)

  2. dig sigok...@127.0.0.1 -p 5335
    ;; Got answer: status: NOERROR, id: 22361
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)

  3. dig google dot com @127.0.0.1
    ;; Got answer:status: NOERROR, id: 50999
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)

Expected/Actual behaviour
This means that upbound should be working. But when I do
dig google dot com I get an answer from 9.9.9.9 by default
;; Got answer:status: NOERROR, id: 16182
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)

  1. nslookup google dot com
    Server: 9.9.9.9
    Address: 9.9.9.9#53

Shouldn’t I be seeing 127.0.0.1?

I seems that unbound is working proplery. However, you system ist not sending its own DNS queries to your unbound resolver.

You can try to check the resolv.conf and that the loopback interface to it:
nano /etc/resolv.conf

then make sure that the text says
nameserver 127.0.0.1

You can find more info on this article: resolv.conf

I would not recommend this. Better to keep a global public DNS on the system hosting Unbound itself. I guess there is Pihole or Adguard running as well. If one of these components fails, you will not have a working DNS resolution on this host, making it challenging to fix :wink:.

Local DNS setting on the host will not have any effect on the local network clients. Meany AdBlock should be working without issue inside the network still.

2 Likes

I ran systemctl is-active unbound-resolvconf.service and it says the service is already inactive. The config file though does say nameserver 9.9.9.9

Yes like I mentioned I installed both pihole and unbound. As I cant change my router’s settings thanks to my ISP, I changed the DNS per device to point to my pihole. In the pihole web console, the DNS upstream server is set to the Unbound address. Yet when I run a nslookup, the queries are resolved by 9.9.9.9 unless I explicitly force it to use the unbound address as seen from the logs above. But doesn’t that defeat the whole purpose of the exercise when unbound doesn’t act as my resolver?

on which device do you execute nslookup. On DietPi or another device?

On the dietPi. nslookup on the device returns the pihole address which I guess is the expected behaviour? But I suppose on dietPi it should be returning the Unbound server address right?

Nope. The Debian operating system, like every operating system, has its own settings for DNS. Under Linux, this is defined in /etc/resolv.conf. Just because Unbound, Pihole or AGH are present on a host does not automatically mean that the host uses them as upstream DNS.

Using Quad9 public DNS on DietPi is perfectly fine and recommended, as I tried to explain above Is Unbound Working Properly? - #3 by Joulinar

1 Like

Thank you so much for your help and taking the time to answer. Really appreciate it.
One more question though, so if the purpose of using Unbound is to act like a recursive DNS resolver, then shouldn’t it be responding at 127.0.0.1?

Also, from your original reply, then would it make sense to use both nameserver 127.0.0.1 and nameserver 9.9.9.9 as fallback given there are already two nameservers/addresses already written in the config file?

You are trying to chase a ghost. There is absolutely no need to set PiHole/Unbound as the upstream DNS in DietPi. Usually this causes more problems than it helps.

1 Like

one suggestion, in my home my router & unbound machine uses nextdns (free public dns resolver) & all other things using dietpi/unbound as dns reslover. in nextdns we are able to see what request those machines sent for resolving.

1 Like

If you are using a free public DNS resolver…go into the Settings, DNS, Upstream DNS Servers and set that as the upstream…bypassing the onboard Unbound built in…the Unbound built in is there to ensure you don’t get spoofed by DNS poisining by going directly to the A record and pulling the address (aka the authorative DNS server)

By not telling onboard pihole to use unbound and point it to your nextdns IP, it goes straight to your nextdns program, then out of the next dns…it will double filter
https://my.nextdns.io/d18888/setup

I believe you can also tell unbound to use DNS-over-HTTPS, which can also point to the nextdns servers as well…over https…completely encrypted

This was on nextdns setup for linux

systemd-resolved

Use the following in /etc/systemd/resolved.conf:

[Resolve]
DNS=45.90.28.0#**d18888**.dns.nextdns.io
DNS=2a07:a8c0::#**d18888**.dns.nextdns.io
DNS=45.90.30.0#**d18888**.dns.nextdns.io
DNS=2a07:a8c1::#**d18888**.dns.nextdns.io
DNSOverTLS=yes

Oh I get it, like you said it is the DNS nameserver being used by my Pi and not the upstream DNS server being used by Pi-hole. I think I had a brain freeze earlier. I kept reading comments over the internet suggesting changing the config of the dietPi to point to the unbound, but I think it’s of no use. The pi-hole is already using it. No special utility in turning the whole pi do the same unless someone has some more specific requirements.

correct :+1: