Dnsmasq: reply error is SERVFAIL

Help Community Help
1

The issue I am facing:
I've been running a raspberry pi for almost a year now, with unbound. Yesterday I did an apt update/upgrade and things were still working fine, but then this morning, DNS started failing and returning SERVFAIL. I spent about two hours following forums with similar issues, double checking configurations, re-installing packages, updating pihole, nothing solved it. But then when I turned on level 4 logging on unbound, it magically started working! I then turned level 4 logging off and it continued to work, so I let it go.
But now this evening it started failing again. Turning on level 4 logging did not solve it this time, so I think that was just a coincidence.
I'm not using DNSSEC
Debug token: https://tricorder.pi-hole.net/3g3MMuvA/

dig test:

$ dig pi-hole.net @127.0.0.1 -p 5335

; <<>> DiG 9.16.33-Raspbian <<>> pi-hole.net @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27331
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; Query time: 3169 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Sat Dec 31 00:33:45 CST 2022
;; MSG SIZE  rcvd: 40

Details about my system:
Raspberry Pi 3 Model B, "Raspbian GNU/Linux 11 (bullseye)"

  • Pi-hole [v5.14.2]
  • FTL [v5.20]
  • Web Interface [v5.18]

What I have changed since installing Pi-hole:
used apt to update the OS
did "pihole -up" to see if it solved the problem - it didn't

2

Your network interface is enxb827eb______ (mac address removed), not eth0.
You can execute ip a to verify the complete interface name.

You can run pihole -r and reconfigure pihole to use the new interface name.

3

Note:
When you want to post the contents of a file or command output you should put the text inside a code block using:

```
$ dig pi-hole.net at127.0.0.1 -p 5335
```

The result will be:

$ dig pi-hole.net at127.0.0.1 -p 5335
4

@rdwebdesign I did a pihole -r and it now shows the network enterface as enxb827xxxxxxxx. Though I'm using the "Recomended" setting of only allowing local requests, and not binding to the network interface.

During the reconfigure, it asked for the upstream provider, and if I choose any of them, things work again. However, they fail instantly when only using the setting for unbound:
Custom 1
127.0.0.1#5335

Also, I turned off the Conditional forwarding, as I read that that could cause a loop. So just to be safe, I turned it off for now. But that hasn't seemed to affect my issue.

5

After three or four days of banging my head, I stumbled across a thread that already talked about this issue: WARNING: Raspbian October 2021 release bullseye + unbound, and the devs know about it. But seems there is a reluctance to put a warning or other user notification about it.

It appears that when I did my apt update/upgrade, it borked up the resolvconf.conf file and created another file that together prevent unbound from working properly. So yes, the issue still exists.

My Solution(from above thread):

  • stop unbound-resolvconf.service
  • Edit /etc/resolvconf.conf
    #resolv_conf=/etc/resolv.conf
    #unbound_conf=unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
  • delete file: /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
  • reboot

After reading that thread several more times, and just for good measure, I also executed the command to replace openresolv with standard resolvconf as well. This should prevent future unintended restarts of unbound.

dpkg-query -s 'openresolv' &> /dev/null && apt -y install resolvconf
6

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.