It started when I added the prefill settings...
[Unit]
Description=Knot Resolver daemon
Documentation=man:kresd.systemd(7)
Documentation=man:kresd(8)
[Service]
Type=notify
WorkingDirectory=/var/cache/knot-resolver
ExecStart=/usr/sbin/kresd --config=/etc/knot-resolver/kresd.conf
User=knot-resolver
Restart=on-abnormal
Sockets=kresd.socket
Sockets=kresd-tls.socket
Sockets=kresd-control@%i.socket
[Install]
WantedBy=kresd.target
changing the knot-resolver configuration file (in /etc/knot-resolver) should NOT affect systemctl. Only changes in /lib/system/system should trigger this message. Are you sure you didn't change anything there, if NOT, strange ...
Nope, it started just after I added the prefill setting. Didn't touch anything else...
I think I'll setup a new Pi and see what I get... 
Thanks!
got it up and running yesterday, but got distracted by this problem. I read this reply from you (I think I’ll setup a new Pi and see what I get), so you will be running into this too...
Looks impressive! I might try something like this some day... Would you mind posting your Unbound config?
Thanks for the heads up!
I've got for files for unbound.
/etc/unbound/unbound.conf, content:
# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/qname-minimisation.conf, content:
server:
# Send minimum amount of information to upstream servers to enhance
# privacy. Only sends minimum required labels of the QNAME and sets
# QTYPE to NS when possible.
# See RFC 7816 "DNS Query Name Minimisation to Improve Privacy" for
# details.
# https://ripe72.ripe.net/presentations/120-unbound_qnamemin_ripe72.pdf
# test: drill txt qnamemintest.internet.nl
# result: "HOORAY - QNAME minimisation is enabled on your resolver :)!"
qname-minimisation: yes
harden-below-nxdomain: yes
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf, content:
server:
# The following line will configure unbound to perform cryptographic
# DNSSEC validation using the root trust anchor.
auto-trust-anchor-file: "/etc/unbound/root.key"
/etc/unbound/unbound.conf.d/unbound.conf, content:
## See wiki: https://github.com/pi-hole/pi-hole/...
#
server:
logfile: /unbound.log
log-time-ascii: yes
verbosity: 1
interface: 127.10.10.2@5552
interface: fdaa:bbcc:ddee:2::5552@5552
#port: 5552
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: yes
# Use this only when you downloaded the list of primary root servers!
root-hints: "/root.hints"
# enable to not answer id.server and hostname.bind queries.
# hide-identity: yes
# enable to not answer version.server and version.bind queries.
# hide-version: yes
# 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
# Aggressive NSEC uses the DNSSEC NSEC chain to synthesize NXDOMAIN
# and other denials, using information from previous NXDOMAINs answers.
aggressive-nsec: yes
# Use Capitalization randomization
# This is an experimental resilience method which uses upper and lower case letters in the question hostname to obtain randomness. Two names with the same spelling but different case should be treated as identical.
# Attackers hoping to poison a DNS cache must guess the mixed-case encoding of the query. This increases the difficulty of such an attack significantly
use-caps-for-id: no
# 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 loose messages in traffix spikes
so-rcvbuf: 1m
# Number of bytes size to advertise as the EDNS reassembly buffer size.
# This is the value put into datagrams over UDP towards peers.
# The actual buffer size is determined by msg-buffer-size(both for TCP and UDP).
# Do not set higher than that value.
# Default is 4096 which is RFC recommended.
# If you have fragmentation reassembly problems,
# usually seen as timeouts, then a value of 1472 can fix it.
# Setting to 512 bypasses even the most stringent path MTU problems,
# but is seen as extreme, since the amount of TCP fallback generated is
# excessive (probably also for this resolver, consider tuning the outgoing tcp number).
edns-buffer-size: 1472
# 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
# Access Control
access-control: fdaa:bbcc:ddee:2::5552/128 allow
# Remote control config section.
remote-control:
control-enable: yes
# Copy of the root for local usage
auth-zone:
name: "."
master: i.root-servers.net
master: f.root-servers.net
master: j.root-servers.net
master: k.root-servers.net
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/root.zone"
As you can see, I no longer use pihole-FTL for DNSSEC (to many problems), both unbound and knot-resolver are capable of doing this.
Thanks for sharing, most appreciated! 
What exactly did you do here (specific commands to allow knot resolver access)?
Do you need to specify this in the config file, or does it work automatically?
Thanks
According to the developers, the Debain release uses the OS-specified root.key but Knot needs write access if you want to auto-maintain it. I just did that with:
sudo chgrp -R knot-resolver /usr/share/dns
sudo chmod -R g+w /usr/share/dns
Then I pointed to that file in the config (I think it's needed to let knot know to auto-maintain it). Syntax changed in v4:
trust_anchors.add_file('/usr/share/dns/root.key')
About the root.hints I'm not sure? Before the latest update to dns-root-data I downloaded it manually anyway and point to it in my config:
hints.root_file = '/var/lib/knot-resolver/root.hints'
I have just tried to piece together stuff I've found on the net or read in the docs. Got a few hints from Reddit and also the Knot chat on Gitter.
I've always been struggling with Linux permissions, please forgive me for asking a stupid question...
I've looked at the group membership of the root group, only user root is a member
I've looked at the group membership of the knot-resolver group, only user knot-resolver is a member.
If I understand these command correctly, you are:
My question:
In order to preserve the original permissions, should root not be a member of the group knot-resolver?
Sorry, I'm certainly no linux expert and I'm probably struggling more than you... there might be a better way of doing it but it seems to work? Maybe it would be enough to give knot-resolver write access to root.key?
Mine looks like this:
pi@pihole:/usr/share/dns $ ls -l
total 12
-rw-r--r-- 1 root root 83 Apr 1 06:40 root.ds
-rw-r--r-- 1 root root 3311 May 9 19:04 root.hints
-rw-r--r-- 1 knot-resolver knot-resolver 415 May 11 06:35 root.key
pi@pihole:/usr/share/dns $
maybe we should ask some help from a Linux expert? @DL6ER, if you please.
I search my system, there are now 3 files on my system:
/etc/unbound/root.hints:
I download this weekly, using cron, command: sudo wget https://www.internic.net/domain/named.root -O /etc/unbound/root.hints
This was recommended in the unbound installation guide lines I used.
/usr/share/dns/root.hints:
This file appears to be there, when installing Raspbian from the latest image. I'm NOT sure if I need to update this regulary…
/var/lib/knot-resolver/root.hints: I've downloaded this file, using the command sudo wget https://www.internic.net/domain/named.root -O /var/lib/knot-resolver/root.hints
I'm not sure this is necessary. Since the Raspbian default file (/usr/share/dns/root.hints) is already there, and you've granted knot-resolver read/write to /usr/share/dns, why not just change hints.root_file = ‘/var/lib/knot-resolver/root.hints’ into hints.root_file = '/usr/share/dns/root.hints'. This would eliminate the third file, and the necessity to update it regulary.
Your thoughts please...
No, root can modify all files without needing any extra permissions for this. This is part of why working as user root is never a good idea on any Linux machine.
Example:
$ echo "123" > testfile
$ cat testfile
123
$ chmod 0000 testfile
$ ls -l testfile
----------. 1 user1 user1 0 May 11 12:02 testfile
$ cat testfile
cat: testfile: Permission denied
$ sudo cat testfile
123
Even though the testfile is owned by user1, root will always be able to read and modify it. Even if there are no permissions for anyone on this file.
Yes, any input from a linux expert would be appreciated.
I think you are right, the one in /usr/share/dns is probably fine. The recent update is quite new and we could always add a cron job to update that one istead. My next installation will probably be like that, my current config is a work in progress because I learn new things as I go.
It will cause the users of the group knot-resolver to be able to write to files in /usr/share/dns.
The said commands will change
to
-rw-rw-r-- 1 root knot-resolver 83 Apr 1 06:40 root.ds
-rw-rw-r-- 1 root knot-resolver 3311 May 9 19:04 root.hints
-rw-rw-r-- 1 knot-resolver knot-resolver 415 May 11 06:35 root.key
One more thing when we're already talking about permissions: Depending on the current permissions in this directory you might also need to set g+x on the directory (not the contained files, so don't use -R here!) to allow group members to be allowed to execute (read as "enter") the said directory. This is probably already the case, check it with
ls -l /usr/share | grep dns
It should return permissions drwxrwxr-- (or even drwxrwxr-x) if everything is correct. The leading d shows that this is a directory.
Don't hesitate to ask if something is still unclear.
Can you confirm this on your system (haven't apllied it yet)?
pi@pihole:~ $ ls -l /usr/share | grep dns
drwxrwxr-x 2 root knot-resolver 4096 May 11 06:35 dns
pi@pihole:~ $
@jpgpi250 I've compiled Unbound now, just one question... I have to create the /etc/unbound/unbound.conf.d/ directory myself right? It's not there after compiling and starting the service...?
Yes. I took the directory structure, used by the Raspbian version of unbound, even though that version is very old. All the files come from that installation (saved them and reused them). The only file that has a personal touch is /etc/unbound/unbound.conf.d/unbound.conf