One all-nighter later... I figured it out. It may not be the perfect solution, eager to read better solutions here.
On an IPv4 system, it looks like (correct me if I'm wrong) the address range 127.x.x.x simply exists. therefore a daemon, such as unbound, stubby and dnscrypt-proxy can be configured using these addresses without any further action to make it work. I've been using 127.10.10.2, 127.10.10.3 and 127.10.10.4, but it looks like you can use whatever you like, as long as it starts with 127.
On an IPv6 system, it turns out there is no such thing. you can only use 0::1, but as I stated, I really wanted to be able to see the different resolvers in the graph.
The solution:
In order to be able to use an 'fd' address in the configuration, you need to ensure the address exists, otherwise the daemon cannot bind to it.
To add the address, simply enter the following command:
sudo ip -6 addr add fd12:3456:789a:1::15b0/128 dev eth0
You can verify the command was successful by checking the 'ifconfig' output:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.57 netmask 255.255.255.224 broadcast 192.168.2.63
inet6 fd12:3456:789a:1::15b0 prefixlen 128 scopeid 0x0
inet6 fe80::3703:77df:647a:75ec prefixlen 64 scopeid 0x20
inet6 2a02:1810:4d02:5602:1481:87d2:f08e:23b5 prefixlen 64 scopeid 0x0
ether b8:27:eb:a8:38:c7 txqueuelen 1000 (Ethernet)
RX packets 20463 bytes 4909000 (4.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 22475 bytes 7118580 (6.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
As you can see, there are now 3 inet6 entries, there were only 2 before you added one.
All you need to do now is ensure your resolver is configured to use the address, example unbound:
interface: 127.10.10.2@5552
interface: fd12:3456:789a:1::15b0@5552
and restart the resolver, e.g. example for unbound:
sudo service unbound restart
For unbound, some additional changes are required in the configuration, dnscrypt-proxy and stubby seem to work with the configurations here:
'do-ip6: no' needs to be changed into 'do-ip6: yes'
'access-control: fd12:3456:789a:1::15b0/128 allow' needs to be added.
After updating the hosts files (add the new addresses and names) and updating the servers (edit /etc/dnsmasq.d/01-pihole.conf, or simply put your resolvers in a different file, so pihole -r or pihole -up want overwrite them), you need to restart dnsmasq (sudo service dnsmasq restart).
Result: see the graph above.
There is still one catch to this. The IPv6 address we added will disappear when you reboot the system. I've been reading and testing various solutions (add a file in /etc/network/interfaces.d/ - no result, edit /etc/dhcpcd.conf - no result) and finally found this document, so I modified /etc/rc.local. The content:
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi
sudo ip -6 addr add fd12:3456:789a:1::15b0/128 dev eth0
sudo ip -6 addr add fd12:3456:789a:1::15b1/128 dev eth0
sudo ip -6 addr add fd12:3456:789a:1::15b2/128 dev eth0
exit 0
Adding the 3 lines to this file, made the system add these IPv6 addresses at reboot, so the daemons could bind to them.
I'm sure this is NOT the best solution, but since I couldn't get anything else to work …
If you have a better solution, eager to find out.
If you have configured all of the resolvers, as described here, you can now test your resolvers with these dig commands:
dig @127.10.10.2 -p 5552 +dnssec www.raspberrypi.org
dig @127.10.10.3 -p 5553 +dnssec www.raspberrypi.org
dig @127.10.10.4 -p 5554 +dnssec www.raspberrypi.org
dig @fd12:3456:789a:1::15b0 -p 5552 +dnssec www.raspberrypi.org
dig @fd12:3456:789a:1::15b1 -p 5553 +dnssec www.raspberrypi.org
dig @fd12:3456:789a:1::15b2 -p 5554 +dnssec www.raspberrypi.org
They should all produce the same result (I'm lucky, they do...)
@DL6ER When I was testing, to find a working solution, I enabled only one resolver in dnsmasq, this to ensure I wasn't getting DNS responses from another resolver. I noticed the graph changed, even if the resolver did not provide an answer. I could submit hundreds of queries to a non working resolver, yet the percentage for that resolver still increased.
‘edit’
typo's
‘/edit’