Query results come back as bogus / servfail

Help
21

Ok.
So I'm pretty sure that this is an unbound issue.
My unbound config contains:

server:
    logfile: "/var/log/unbound/unbound.log"
    verbosity: 3

But the log file does not exist
I'm getting constant SERVFAIL results, for any domain randomly, and then it will load.
Pihole log is telling my domains are being forwarded, but the reply is N/A
If I restart unbound, it seems to work for some short time, and them the same behaviour reappears.
I'm completely lost as to what to do now.
Unless my Google Fu is crap, I can't seem to find much help or support.

22

You can't go wrong uninstalling unbound and reinstalling it again per the guide.

23

Yeah this was probably going to be my next idea.
Uninstall via sudo apt purge unbound right?

24

That will work.

25

Is there a 'better' way to uninstall?

26

So I uninstalled unbound, and reinstalled it
I still get SERVFAIL for every query, effectively losing web connectivity.
If I switch back to 'standard' upstream, such as Google I'm able to browse.

28

Try commenting out the logfile line, which will make unbound use the existing syslog. Odd that the log did not exist at the specified location - perhaps a permission problem.

29

Errmmm, what?

I'll comment it out and restart unbound.
Edit:
I did leave it commented out, how do I check syslog for unbound entries?

31

Not sure I follow tbh.

Pihole is acting as DHCP server.
Never had problems before, and I get SERVFAIL for any domain, not just the Xbox / Microsoft one's, they just happened to be the ones I grabbed.

32

I think what msatter is saying is that gameclipscontent-d2017.xboxlive.com.local is not the same as gameclipscontent-d2017.xboxlive.com

33

Sorry, please excuse my ignorance here, but does it bear any significance?

34

Anything ending in .local will never be resolved on the internet, that is a reserved domain that can not be used anywhere but internally on your network. It will never be DNSSEC enabled unless you set up an authoritative DNS server that signs that domain.

35

Hmmm, interesting.
Thanks, I didn't know that... obviously lol
When using Google as upstream, the domains showing in log arent appended with .local
I'm now thinking this is significant?
All my clients in the query log are as client1.local
Does this mean anything?

36

I have tried another uninstall and install of unbound...still see the same behaviour?
Any more ideas for diagnosis?
Seems every query is resulting in SERVFAIL

38

I followed the guide on the pi-hole docs page, here so my config is as exactly that:
/etc/unbound/unbound.conf.d/pi-hole.conf

server:
    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    port: 5353
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the servers authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    # TTL bounds for cache
    cache-min-ttl: 3600
    cache-max-ttl: 86400

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

pi@pi-hole:~ $ unbound -d -vvvvv
[1556624192] unbound[9613:0] notice: Start of unbound 1.6.0.
[1556624192] unbound[9613:0] debug: increased limit(open files) from 1024 to 4140
[1556624192] unbound[9613:0] debug: creating udp4 socket 127.0.0.1 5353
[1556624192] unbound[9613:0] warning: so-rcvbuf 1048576 was not granted. Got 327680. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
[1556624192] unbound[9613:0] debug: creating tcp4 socket 127.0.0.1 5353
[1556624192] unbound[9613:0] debug: creating tcp4 socket 127.0.0.1 8953
[1556624192] unbound[9613:0] debug: switching log to syslog
40

Thanks for taking the time to help
Do you mean add this to /etc/unbound/unbound.conf.d/pi-hole.conf
Would you mind explaining what this does and why?

42

Thanks for that.
I have added to my config file and will monitor for a while...im away from home now so will check later.
Im still puzzled as to why it would work, and then not work, with no changes to setups / configurations etc.?!
As far as I am aware the version of unbound running is 1.6.0

44 
pi@pi-hole:~ $ sudo service unbound stop
pi@pi-hole:~ $ unbound -d -vvvvv
[1556633376] unbound[15003:0] notice: Start of unbound 1.6.0.
[1556633376] unbound[15003:0] debug: increased limit(open files) from 1024 to 4140
[1556633376] unbound[15003:0] debug: creating udp4 socket 127.0.0.1 5353
[1556633376] unbound[15003:0] warning: so-rcvbuf 1048576 was not granted. Got 327680. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
[1556633376] unbound[15003:0] debug: creating tcp4 socket 127.0.0.1 5353
[1556633376] unbound[15003:0] debug: creating tcp4 socket 127.0.0.1 8953
[1556633376] unbound[15003:0] debug: switching log to syslog
46

Yeah I can confirm that that didn't help.
Still seeing the SERVFAIL response, and effectively losing connectivity.
Is it worth trying to upgrade unbound do you think?

47

No. The problem is not due to your unbound version. I have four instances of unbound 1.60 running and zero problems with any of them.