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.
Thanks, will try this later.
But, doesn't using upstream servers with Unbound kind of defeat the point of unbound, or do I misunderstand the usage of unbound?
hmmm ok,
I think im part way to understanding 
I use pi-hole as DHCP, as I am unable to manually set DNS resolvers on my ISP provided router.
I can have DNSSEC working, without unbound.
If I choose, for example, Cloudflare as my upstream in Pi-hole settings, and select DNSSEC it works as expected....so effectively I don't need Unbound, as it isn't 'working' as a recursive server?
Yeah I'm certain. Which is also part of my confusion on this problem.
I'll be sure to double check it later when I'm back home.
I can confirm that if I select upstream in the DNS settings (Cloudflare) and tick the enable dnssec, everything works ok, and dnssec tests are passed.
So this would be the same as the above 'solution', i.e. using unbound with forward-control enabled?
pi@pi-hole:~ $ dnsmasq -v
Dnsmasq version 2.76 Copyright (c) 2000-2016 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
Any more thoughts on this?
I cant help but think that using Unbound + Cloudflare is kind of redundant?
Short update, installed the latest pihole version today and still see the SERVFAIL error when using unbound.
Yea, I tried adding forward-zone to the unbound config, with Cloudflare as the upstream and it works....but it's kind of redundant isn't it?
No advantage to that method over the 'normal' way?
Sorry but I don't understand what you mean?
Does anyone know of any other resources / forums for unbound?
Either they don't exist or my Google Fu is weak 
sorry to drag this one up again, really hoping for a solution to the unbound problem
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.