Query results come back as bogus / servfail

I've created the log file, but it's not getting written to?
I guess I'll need to chmod it?

pi@pi-hole:~ $ ls /var/log | grep unbound
-rw-r--r--  1 unbound     unbound     0 May  6 21:33 unbound.log

I've also got the following in the conf file

chroot: “”
interface: 0.0.0.0

Log file still isn't being written to

Maybe another twist...

pi@pi-hole:~ $ sudo service unbound status
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2019-05-06 21:59:18 BST; 2s ago
     Docs: man:unbound(8)
  Process: 4331 ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS (code=exited, status=1/FAILURE)
  Process: 4325 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
  Process: 4320 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
 Main PID: 4331 (code=exited, status=1/FAILURE)
lines 1-8...skipping...
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2019-05-06 21:59:18 BST; 2s ago
     Docs: man:unbound(8)
  Process: 4331 ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS (code=exited, status=1/FAILURE)
  Process: 4325 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
  Process: 4320 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
 Main PID: 4331 (code=exited, status=1/FAILURE)
   CGroup: /system.slice/unbound.service

May 06 21:59:18 pi-hole unbound[4331]: [1557176357] unbound[4331:0] fatal error: could not set up remote-control
May 06 21:59:18 pi-hole systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE
May 06 21:59:18 pi-hole systemd[1]: unbound.service: Unit entered failed state.
May 06 21:59:18 pi-hole systemd[1]: unbound.service: Failed with result 'exit-code'.
May 06 21:59:18 pi-hole systemd[1]: unbound.service: Service hold-off time over, scheduling restart.
May 06 21:59:20 pi-hole systemd[1]: Stopped Unbound DNS server.
May 06 21:59:20 pi-hole systemd[1]: Starting Unbound DNS server...

I've managed to get in ound running, seems it was an error with chroot in the config.
Log file at /var/log/unbound.log is being written.
I'm still getting servfail for some domains though.
I've reinstalled unbound 2 times already, and still see the same behaviour

Sorry, my bad.

Yeah, so it seems to be random, but for example, youtube.com is giving a servfail error.

Pretty much everything to be honest.
I have to revert back to regular upstream servers, otherwise I cannot 'freely' browse the web, be it by a browser or any app.

Thanks again, @msatter...
My unbound pi-hole conf file:

pi@pi-hole:~ $ sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

File: /etc/unbound/unbound.conf.d/pi-hole.conf                
server:
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound.log"
    verbosity: 4

    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 isabsent, 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

    interface: 0.0.0.0

    chroot: ""

running the netstat command before creating any new file gives no results:

pi@pi-hole:~ $ sudo netstat -tulpn | grep unbound
pi@pi-hole:~ $

control.conf file created and rights set:

pi@pi-hole:/etc/unbound/unbound.conf.d $ ls
total 24K
drwxr-xr-x 2 root root 4.0K May  7 09:13 .
drwxr-xr-x 3 root root 4.0K Apr 27 10:28 ..
-rw-r--r-- 1 root root   42 May  7 09:13 control.conf
-rw-r--r-- 1 root root 1.7K May  6 22:20 pi-hole.conf
-rw-r--r-- 1 root root  302 Feb 28  2018 qname-minimisation.conf
-rw-r--r-- 1 root root  190 Feb 28  2018 root-auto-trust-anchor-file.conf

re-run the netstat command:

pi@pi-hole:/etc/unbound/unbound.conf.d $ sudo netstat -tulpn | grep unbound
tcp        0      0 0.0.0.0:5353            0.0.0.0:*               LISTEN      8215/unbound
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           8215/unbound

And I can confirm that /etc/unbound/unbound.conf is untouched, and looks as you mention above.

Before I created the new file /etc/unbound/control.conf the netstat command output nothing.

I don't know, this is going beyond my knowledge to be honest :man_shrugging:
What I can say, is with all the changes above, including the new control.conf file, I still see the servfail error on multiple domains.
tailing pihole.log shows the servfail errors, but looking in the query log oin the GUI, some of the requests are listed as forwarded, but the reply is N/A

sorry, im not following you.

chroot: "" present in the conf file:

pi@pi-hole:~ $ unbound -d -vvvvv
[1557225152] unbound[24252:0] notice: Start of unbound 1.6.0.
[1557225152] unbound[24252:0] debug: increased limit(open files) from 1024 to 4140
[1557225152] unbound[24252:0] debug: creating udp4 socket 0.0.0.0 5353
[1557225152] unbound[24252: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.
[1557225152] unbound[24252:0] debug: creating tcp4 socket 0.0.0.0 5353
[1557225152] unbound[24252:0] error: cannot open pidfile /run/unbound.pid: Permission denied
[1557225152] unbound[24252:0] debug: cannot chown 113.116 /run/unbound.pid: Operation not permitted
[1557225152] unbound[24252:0] debug: chdir to /etc/unbound
[1557225152] unbound[24252:0] warning: unable to initgroups unbound: Operation not permitted
[1557225152] unbound[24252:0] fatal error: unable to set group id of unbound: Operation not permitted

pi@pi-hole:~ $ sudo unbound -d -vvvvv
[1557225404] unbound[24724:0] notice: Start of unbound 1.6.0.
[1557225404] unbound[24724:0] debug: increased limit(open files) from 1024 to 4140
[1557225404] unbound[24724:0] debug: creating udp4 socket 0.0.0.0 5353
[1557225404] unbound[24724:0] debug: creating tcp4 socket 0.0.0.0 5353
[1557225404] unbound[24724:0] debug: chdir to /etc/unbound
[1557225404] unbound[24724:0] debug: drop user privileges, run as unbound
[1557225404] unbound[24724:0] debug: switching log to /var/log/unbound.log

and if I remove chroot: "":

pi@pi-hole:~ $ sudo unbound -d -vvvvv
[1557225404] unbound[24724:0] notice: Start of unbound 1.6.0.
[1557225404] unbound[24724:0] debug: increased limit(open files) from 1024 to 4140
[1557225404] unbound[24724:0] debug: creating udp4 socket 0.0.0.0 5353
[1557225404] unbound[24724:0] debug: creating tcp4 socket 0.0.0.0 5353
[1557225404] unbound[24724:0] debug: chdir to /etc/unbound
[1557225404] unbound[24724:0] debug: drop user privileges, run as unbound
[1557225404] unbound[24724:0] debug: switching log to /var/log/unbound.log

I will make this change also, thanks. But I get the servfail error whilst im connected to the network at home, i.e. not through VPN.

should I add this to my unbound pi-hole conf file?

I've added this to my unbound Pi-Hole conf file, and I still get the servfail errors.
I've just noticed some other files in the conf.d folder:

pi@pi-hole:~ $ ls /etc/unbound/unbound.conf.d/
total 24K
drwxr-xr-x 2 root root 4.0K May  7 09:13 .
drwxr-xr-x 3 root root 4.0K Apr 27 10:28 ..
-rw-r--r-- 1 root root   42 May  7 09:13 control.conf
-rw-r--r-- 1 root root 1.8K May  7 22:19 pi-hole.conf
-rw-r--r-- 1 root root  302 Feb 28  2018 qname-minimisation.conf
-rw-r--r-- 1 root root  190 Feb 28  2018 root-auto-trust-anchor-file.conf

I created the control.conf as further up the thread.

qname-minimisation.conf contains

server:
    qname-minimisation: yes

I have removed chroot: "" from Pi-hole conf and

# The number of threads to create to serve clients. Use 1 for no threading.
num-threads: 1
#for build version of unbound
outgoing-range: 465
num-queries-per-thread: 25

And I've left edns-buffer-size at 512 and still have interface: 0.0.0.0 as @DL6ER suggested

Ok, I've set interface: 127.0.0.1
The guide on the pihole docs doesn't mention that in the example conf file they have listed. I guess it's just 'making sure'?

Ok, I'll leave it set at 127.0.0.1 to be certain

And to disable qname-minimalisation I set it to no in the config file?

Ok thanks again for you time and help
I've set it no, will leave it over night and check the logs and report back in the morning

So checking the logs this morning, I still see the SERVFAIL error with qname-minimisation: no
Also, changing that to no seemed to completely kill my web access, whereas with it set to yes, I still can access some sites, but get servfail for others.
I have set qname-minimisation back to yes and web access is back, but still getting SERVFAIL on some queries, this mornings examples include, pushbullet api, reddit.com and youtube.com again...all of which worked previously (and work OK when not using unbound)

Yes, for now I have reverted back to using Cloudfare upstream.
When using unbound, I had no upstreams selected in the gui, only 'custom; and entered 127.0.0.1#5353 as detailed in the guide

I followed the guide on the pi-hole docs page
This guide instructs to have no upstream servers ticked, only custom: 127.0.0.1#5353

just another observation from me.....
I noticed that the root.hints was updated recently.
My version on my machine is outdated by 1 month.
I guess this isn't normally an issue.

any further ideas at all?
Ive just made a little test, and it makes no sense to me!
Pi-hole configured as per the unbound guide (no upstream servers selected, custom IPV4 - 127.0.01.1#5353)
I see many servfails in the log...
Taking one as an example:

May  9 15:31:11 dnsmasq[15191]: query[A] feedr.search.sky.com from 192.168.0.128
May  9 15:31:11 dnsmasq[15191]: forwarded feedr.search.sky.com to 127.0.0.1
May  9 15:31:11 dnsmasq[15191]: forwarded feedr.search.sky.com to 127.0.0.1
May  9 15:31:11 dnsmasq[15191]: validation feedr.search.sky.com is BOGUS
May  9 15:31:11 dnsmasq[15191]: reply error is SERVFAIL

If I then dig this domain I see a no error reply?

pi@pi-hole:~ $ dig feedr.search.sky.com @127.0.0.1 -p5353

; <<>> DiG 9.10.3-P4-Raspbian <<>> feedr.search.sky.com @127.0.0.1 -p5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40055
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;feedr.search.sky.com.          IN      A

;; ANSWER SECTION:
feedr.search.sky.com.   1962    IN      CNAME   feedr3.search.sky.com.edgekey.net.
feedr3.search.sky.com.edgekey.net. 1963 IN CNAME e5591.b.akamaiedge.net.
e5591.b.akamaiedge.net. 1963    IN      A       104.78.176.213

;; Query time: 1 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Thu May 09 15:43:28 BST 2019
;; MSG SIZE  rcvd: 145

This pattern seems to be totally random, i.e. I can pick another servfail error from the log, dig it, and return SERVFAIL?

Yes you're right.
I disabled DNSSEC again and the behaviour returned to as before.... servfail error with no bogus results.