###############################################################################
# DHCP SERVER CONFIG FILE AUTOMATICALLY POPULATED BY PI-HOLE WEB INTERFACE. #
# ANY CHANGES MADE TO THIS FILE WILL BE LOST ON CHANGE #
###############################################################################
dhcp-authoritative
dhcp-range=192.168.0.2,192.168.0.254,24h
dhcp-option=option:router,192.168.0.1
dhcp-leasefile=/etc/pihole/dhcp.leases
#quiet-dhcp
domain=local
#quiet-dhcp6
#enable-ra
dhcp-option=option6:dns-server,[::]
dhcp-range=::100,::1ff,constructor:eth0,ra-names,slaac,24h
ra-param=*,0,0
As said before, Pi-hole didn't change DHCP configuration in Beta 5.0:
DHCP settings in your 02-pihole-dhcp.conf do look exactly the same as in Pihole v4 (I just double-checked that).
But I am not going to dismiss your observation.
I am just not convinced yet that your observation could not be explained by a change in client behaviour.
Note that if you enable Pi-hole's DHCP server, it may take a while until your clients will pick up new DHCP information from Pi-hole, i.e. until their existing lease expires. It would depend on your previous DHCP server's settings how long that period will be.exactly.
Are you positive all your clients did renew their DHCP leases with Pi-hole, e.g. by enforcing lease renewal through dis- and reconnecting to your network or power cycling devices?
Even then, with IPv6, getting your clients to actually make use of Pi-hole remains tricky (click for more)
While Pi-hole offers its DHCP services for SLAAC as well as stateless and as stateful DHCPv6 clients alike, a client decides which of these methods it uses.
A DNS server is only guaranteed to be used if your clients register in your network via Stateful DHCPv6.
Clients that do use this method will get assigned an IPv6 address from the ::100 to ::1ff range in addition to any other IPv6 addresses they may have calculated using SLAAC.
In case of stateless DHCPv6 or SLAAC, Pi-hole can only offer a DNS server.
Pi-hole can neither force a client to query for that offer nor to accept it.
Again, it will depend on your client's OS which method it uses. Win7/8 do DHCPv6, Android will do only SLAAC, and Win10 and iOS support SLAAC and DHCPv6, though I would be at a loss to describe when or why the latter would prefer one over the other.
You didn't perhaps ugrade your clients from Win7/8 to Win10 lately?
Such a change may also explain why your clients behave differently.
Also, maybe it is not Pi-hole that changed, but your network configuration:
Your Pi-hole machine sports a tun0 interface in addition to eth0.
If you look closely, Pi-hole binds its DHCP service to the eth0 interface exclusivley.
If you had been using another interface with Pi-hole v4 or only recently changed your network configuration to include that new interface, that might explain why clients do not consider Pi-hole at all.
Which network interface to you intend your Pi-hole to use?
If neither ensuring DHCP lease renewal nor a recent client side shift from Win7/8 to Win10, nor tun0 vs. eth0 contribute towards a solution or at least an explanation, Dan's suggestion of changes in dnsmasq potentially having side effects becomes the strongest remaining suspect for a cause.
Thanks for your detailed reply. The tun0 interface is for wireguard and I have been using that for a few months now with no issue. I have powercycled some devices and they do not get the Pi-hole's IPv6 address for DNS. They are iOS devices and OSX devices. It's not a deal breaker obviously, as my devices are functioning correctly and ads are getting blocked regardless. Thank you for your help.
One additional thing would be to add
log-dhcp
to /etc/dnsmasq.d/99-something.conf and pihole restartdns
Then reboot the said devices and check your /var/log/pi-hole.log for dhcp messages. I'm currently not at home where my dual-stack setup is, however, I'm pretty sure sent RAs are logged as well.
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 available DHCP range: 192.168.0.2 -- 192.168.0.254
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 client provides name: XXXXiPhone
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 DHCPREQUEST(eth0) 192.168.0.161 e0:33:8e:7f:96:1a
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 tags: known, eth0
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 DHCPACK(eth0) 192.168.0.161 e0:33:8e:7f:96:1a XXXX-iPhone
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 requested options: 1:netmask, 121:classless-static-route, 3:router,
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 requested options: 6:dns-server, 15:domain-name, 119:domain-search,
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 requested options: 252
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 next server: 192.168.0.222
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 1 option: 53 message-type 5
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 4 option: 54 server-identifier 192.168.0.222
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 4 option: 51 lease-time 1d
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 4 option: 58 T1 12h
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 4 option: 59 T2 21h
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 4 option: 1 netmask 255.255.255.0
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 4 option: 28 broadcast 192.168.0.255
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 4 option: 6 dns-server 192.168.0.222
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 5 option: 15 domain-name local
May 2 13:37:53 dnsmasq-dhcp[8690]: 4225864336 sent size: 4 option: 3 router 192.168.0.1
May 2 13:37:53 dnsmasq-dhcp[8690]: RTR-SOLICIT(eth0)
This is what the log shows after reconnecting my iPhone. There is no IPv6 DNS address being provided.
Do you have static leases or reservations set for these clients?
Yes, all my clients have static leases.
Did you provide fixed IPv6 addresses for yor clients as well?
Then this would definitely be a bug, at least for clients that support Stateful DHCPv6.
If not, it would seem your clients wouldn't have requested IPv6 addresses either, but then your log excerpt doesn't show any Router Advertisements (RA) either.
I am seeing RAs in my logs, e.g. RTR-ADVERT(wlan0) fd00:: - I set that ULA prefix for my local network.
Could you check again for those RAs?
I used the following command for a filtered live view of the log:
tail -n 25 -f /var/log/pihole.log | grep dhcp
Here's what my v5 log looks like for two different clients (click for more)
Raspbian client receiving a DNS server IPv6 address;
02:40:58 dnsmasq[1290]: started, version pi-hole-2.81 cachesize 10000
02:40:58 dnsmasq[1290]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCP$
02:40:58 dnsmasq-dhcp[1290]: DHCP, IP range 192.168.0.201 -- 192.168.0.251, lease time 1d
02:40:58 dnsmasq-dhcp[1290]: DHCPv6, IP range ::100 -- ::1ff, lease time 1d, template for wlan0
02:40:58 dnsmasq-dhcp[1290]: DHCPv4-derived IPv6 names on wlan0
02:40:58 dnsmasq-dhcp[1290]: router advertisement on wlan0
02:40:58 dnsmasq-dhcp[1290]: DHCPv6, IP range fd00::100 -- fd00::1ff, lease time 1d, constructed for wlan0
02:40:58 dnsmasq-dhcp[1290]: DHCPv4-derived IPv6 names on fd00::, constructed for wlan0
02:40:58 dnsmasq-dhcp[1290]: router advertisement on fd00::, constructed for wlan0
02:40:58 dnsmasq-dhcp[1290]: RTR-ADVERT(wlan0) fd00::
02:40:58 dnsmasq-dhcp[1290]: 10657707 available DHCP range: fd00::100 -- fd00::1ff
02:40:58 dnsmasq-dhcp[1290]: 10657707 vendor class: 40712
02:40:58 dnsmasq-dhcp[1290]: 10657707 client MAC address: 00:e0:4e:ba:dd:ad
02:40:58 dnsmasq-dhcp[1290]: 10657707 client provides name: zero
02:40:58 dnsmasq-dhcp[1290]: 10657707 DHCPSOLICIT(wlan0) 00:01:00:01:24:3d:de:31:b8:27:eb:86:22:f5
02:40:58 dnsmasq-dhcp[1290]: 10657707 DHCPREPLY(wlan0) fd00::1a7 00:01:00:01:24:3d:de:31:b8:27:eb:86:22:f5 zero
02:40:58 dnsmasq-dhcp[1290]: 10657707 requested options: 23:dns-server, 24:domain-search, 31:sntp-server,
02:40:58 dnsmasq-dhcp[1290]: 10657707 requested options: 39:FQDN, 82, 83
02:40:58 dnsmasq-dhcp[1290]: 10657707 tags: dhcpv6, wlan0
02:40:58 dnsmasq-dhcp[1290]: 10657707 sent size: 14 option: 1 client-id 00:01:00:01:24:4d:df:31:b8:27:eb:86:22:f5
02:40:58 dnsmasq-dhcp[1290]: 10657707 sent size: 14 option: 2 server-id 00:01:00:01:26:4e:2f:9a:b8:27:eb:86:22:f5
02:40:58 dnsmasq-dhcp[1290]: 10657707 sent size: 0 option: 14 rapid-commit
02:40:58 dnsmasq-dhcp[1290]: 10657707 sent size: 40 option: 3 ia-na IAID=1312286479 T1=43200 T2=75600
02:40:58 dnsmasq-dhcp[1290]: 10657707 nest size: 24 option: 5 iaaddr fd00::1a7 PL=86400 VL=86400
02:40:58 dnsmasq-dhcp[1290]: 10657707 sent size: 9 option: 13 status 0 success
02:40:58 dnsmasq-dhcp[1290]: 10657707 sent size: 1 option: 7 preference 255
02:40:58 dnsmasq-dhcp[1290]: 10657707 sent size: 16 option: 23 dns-server fd00::1d43:338c:9909:50c1
02:40:58 dnsmasq-dhcp[1290]: 10657707 sent size: 23 option: 39 FQDN zero.myown.lan
Android smartphone doesn't request it:
02:42:36 dnsmasq-dhcp[1290]: DHCPv6, IP range fd00::100 -- fd00::1ff, lease time 1d, constructed for wlan0
02:42:36 dnsmasq-dhcp[1290]: DHCPv4-derived IPv6 names on fd00::, constructed for wlan0
02:42:36 dnsmasq-dhcp[1290]: router advertisement on fd00::, constructed for wlan0
02:42:49 dnsmasq-dhcp[1290]: RTR-ADVERT(wlan0) fd00::
02:42:50 dnsmasq-dhcp[1290]: 829116821 available DHCP range: 192.168.0.201 -- 192.168.0.251
02:42:50 dnsmasq-dhcp[1290]: 829116821 vendor class: android-dhcp-7.0.2
02:42:50 dnsmasq-dhcp[1290]: 829116821 client provides name: KIW-X64-9a4afeebad9d1005
02:42:53 dnsmasq-dhcp[1290]: 829116821 DHCPDISCOVER(wlan0) 50:01:d9:da:be:ef
02:42:53 dnsmasq-dhcp[1290]: 829116821 tags: wlan0
02:42:53 dnsmasq-dhcp[1290]: 829116821 DHCPOFFER(wlan0) 192.168.0.226 50:01:d9:da:be:ef
02:42:53 dnsmasq-dhcp[1290]: 829116821 requested options: 1:netmask, 3:router, 6:dns-server, 15:domain-name,
02:42:53 dnsmasq-dhcp[1290]: 829116821 requested options: 26:mtu, 28:broadcast, 51:lease-time, 58:T1,
02:42:53 dnsmasq-dhcp[1290]: 829116821 requested options: 59:T2
02:42:53 dnsmasq-dhcp[1290]: 829116821 next server: 192.168.0.130
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 1 option: 53 message-type 2
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 4 option: 54 server-identifier 192.168.0.130
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 4 option: 51 lease-time 1d
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 4 option: 58 T1 12h
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 4 option: 59 T2 21h
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 4 option: 1 netmask 255.255.255.0
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 4 option: 28 broadcast 192.168.0.255
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 4 option: 6 dns-server 192.168.0.130
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 9 option: 15 domain-name myown.lan
02:42:53 dnsmasq-dhcp[1290]: 829116821 sent size: 4 option: 3 router 192.168.0.1
02:42:55 dnsmasq-dhcp[1290]: RTR-ADVERT(wlan0) fd00::
02:43:10 dnsmasq-dhcp[1290]: RTR-SOLICIT(wlan0) 50:01:d9::da:be:ef
02:43:10 dnsmasq-dhcp[1290]: RTR-ADVERT(wlan0) fd00::
And here's my v4 log, just for one client
Same Android smartphone as above:
02:53:47 dnsmasq[17507]: started, version pi-hole-2.80 cachesize 10000
02:53:47 dnsmasq[17507]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
02:53:47 dnsmasq-dhcp[17507]: DHCP, IP range 192.168.0.201 -- 192.168.0.250, lease time 1d
02:53:47 dnsmasq-dhcp[17507]: DHCPv6, IP range ::100 -- ::1ff, lease time 1d, template for eth0
02:53:47 dnsmasq-dhcp[17507]: DHCPv4-derived IPv6 names on eth0
02:53:47 dnsmasq-dhcp[17507]: router advertisement on eth0
02:53:47 dnsmasq-dhcp[17507]: DHCPv4-derived IPv6 names on eth0
02:53:47 dnsmasq-dhcp[17507]: router advertisement on eth0
02:53:47 dnsmasq-dhcp[17507]: DHCPv6, IP range fd00::100 -- fd00::1ff, lease time 1d, constructed for eth0
02:53:47 dnsmasq-dhcp[17507]: DHCPv4-derived IPv6 names on fd00::, constructed for eth0
02:53:47 dnsmasq-dhcp[17507]: router advertisement on fd00::, constructed for eth0
02:53:47 dnsmasq-dhcp[17507]: DHCPv4-derived IPv6 names on fd00::, constructed for eth0
02:53:47 dnsmasq-dhcp[17507]: router advertisement on fd00::, constructed for eth0
02:53:47 dnsmasq-dhcp[17507]: RTR-ADVERT(eth0) fd00::
02:55:01 dnsmasq-dhcp[17507]: DHCPDISCOVER(eth0) 50:01:d9:da:be:ef
02:55:01 dnsmasq-dhcp[17507]: DHCPOFFER(eth0) 192.168.0.231 50:01:d9:da:be:ef
02:55:01 dnsmasq-dhcp[17507]: DHCPREQUEST(eth0) 192.168.0.231 50:01:d9:da:be:ef
02:55:01 dnsmasq-dhcp[17507]: DHCPACK(eth0) 192.168.0.231 50:01:d9:da:be:ef KIW-X64-9a4afeebad9d1005
02:55:02 dnsmasq-dhcp[17507]: RTR-SOLICIT(eth0) 50:01:d9:da:be:ef
02:55:02 dnsmasq-dhcp[17507]: RTR-ADVERT(eth0) fd00::
02:55:03 dnsmasq-dhcp[17507]: SLAAC-CONFIRM(eth0) fd00::5201:d9ff:feda:beef KIW-X64-9a4afeebad9d1005
02:55:03 dnsmasq-dhcp[17507]: SLAAC-CONFIRM(eth0) fd00::5201:d9ff:feda:beef KIW-X64-9a4afeebad9d1005
@DL6ER, it would seem at least the debug log output format has changed, e.g. I can't grep any "sent size" entries with v4, while v5 has plenty.
Also, in contrast to v4, my v5 logs do not show any SLAAC-CONFIRMs in my few minutes sampling period.
Hi again. My clients do their own thing with regards to IPv6, generating their own IPv6 addresses. I have noticed though, that PiHole used to generate some IPv6 addresses for clients in PiHole 4 that I could see in the DHCP section of PiHole but that is no longer the case (only shows IPv4 addresses).
Inputting your command shows the following:
May 2 21:54:19 dnsmasq- dhcp [8690]: no address range available for DHCPv6 request via eth0
Sorry, above command was meant for a filtered live view of the debug log, for watching dhcp log messages as they happen.
If you want to search your existing debug log instead, use
grep dhcp /var/log/pihole.log
Is that line followed by a later DHCPv6, IP range ::100 -- ::1ff, lease time 1d or similar?
It still does so on my Beta 5.0, if a client requests it:
02:40:58 dnsmasq-dhcp[1290]: 10657707 DHCPSOLICIT(wlan0) 00:01:00:01:24:3d:de:31:b8:27:eb:86:22:f5
02:40:58 dnsmasq-dhcp[1290]: 10657707 DHCPREPLY(wlan0) fd00::1a7 00:01:00:01:24:3d:de:31:b8:27:eb:86:22:f5 zero
This is a Raspbian client getting assigned fd00::1a7 as IPv6 address.
My Android smartphone does never request a DHCPv6 lease.
Yes, it was a live view and all I had was that line repeating over and over. Disconnecting my iphone and reconnecting it to the network yields this (live):
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 available DHCP range: 192.168.0.2 -- 192.168.0.254
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 client provides name: XXXXiPhone
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 DHCPREQUEST(eth0) 192.168.0.161 e0:33:8e:ca:fe:da
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 tags: known, eth0
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 DHCPACK(eth0) 192.168.0.161 e0:33:8e:ca:fe:da XXXX-iPhone
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 requested options: 1:netmask, 121:classless-static-route, 3:router,
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 requested options: 6:dns-server, 15:domain-name, 119:domain-search,
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 requested options: 252
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 next server: 192.168.0.222
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 1 option: 53 message-type 5
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 4 option: 54 server-identifier 192.168.0.222
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 4 option: 51 lease-time 1d
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 4 option: 58 T1 12h
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 4 option: 59 T2 21h
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 4 option: 1 netmask 255.255.255.0
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 4 option: 28 broadcast 192.168.0.255
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 4 option: 6 dns-server 192.168.0.222
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 5 option: 15 domain-name local
May 2 22:13:14 dnsmasq-dhcp[749]: 2211907297 sent size: 4 option: 3 router 192.168.0.1
May 2 22:13:14 dnsmasq-dhcp[749]: RTR-SOLICIT(eth0)
May 2 22:13:15 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:15 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:15 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:15 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:15 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:15 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:15 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:25 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:31 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:43 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:49 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
May 2 22:13:49 dnsmasq-dhcp[749]: no address range available for DHCPv6 request via eth0
(You can format command output by highlighting some text and selecting the </> Preformatted text option from the menu. I have edited your post accordingly.)
Now that would explain why Pi-hole would not provide an IPv6 address for clients requesting one.
Please check whether there has been any at sometime in your log:
grep "v6, IP range" /var/log/pihole.log
Did you have a ULA prefix configured on your router previously?
Would you be able to do so now?
Hi. Running the command yields:
May 2 13:37:25 dnsmasq-dhcp[8690]: DHCPv6, IP range ::100 -- ::1ff, lease time 1d, template for eth0
May 2 21:58:59 dnsmasq-dhcp[749]: DHCPv6, IP range ::100 -- ::1ff, lease time 1d, template for eth0
May 2 22:25:54 dnsmasq-dhcp[4750]: DHCPv6, IP range ::100 -- ::1ff, lease time 1d, template for eth0
My router is pretty basic (Velop) and I have not found the option to set ULAs.
So Pi-hole did pick up a DHCPv6 range as configured via 02-pihole-dhcp.conf.
However, it seems Pi-hole isn't aware of any IPv6 prefix.
As a prefix is a mandatory part of an IPv6 address, Pi-hole cannot hand out any IPv6 addresses without one.
Your router should at least provide a global prefix (matching the 2000::/3 range).
And your existing global 2403:something IPv6 addresses prove your clients are aware of it.
This indicates that your router may still consider itself as a DHCPv6 server, and it may not delegate your ISP's prefix to Pi-hole's DHCP server.
Did you change your router's IPv6 configuration lately?
Or maybe you can pinpoint this to a date where your router received a firmware update?
Now that’s a good question. I have upgraded my router’s firmware a couple of days ago but I am sure I noticed the problem after installing the beta. Too many variables now!
Can you recall how many days ago that was, and how many days ago you switched to Beta 5.0?
The only way you could be sure would be to downgrade your router to the previous firmware version. I don't know whether your router would allow that, though.
Had to look through my google history to work things out. I installed Pihole 5 beta on the 27th of April. I then upgraded my router on the 28th. Too close for me to tell where the problem lies. I could downgrade the router firmware but it’s a bit of a PITA as there are 4 nodes to do.
Sounds complicated.
If chances are that this might brick your router, I would not recommend it.
I'll see if I can tweak my settings to lose a prefix and report back on it, but this would have to wait until I can risk my network. There will be 3rd party complaints if I do so right now. 
It's not really, just a bit annoying. Anyway, out of frustration, I rolled back to the router's prior firmware but this has made no difference. It's therefore looking like Pihole 5 might be the problem after all.
If you have updated your 5.0 beta since Easter, it now included dnsmasq V 2.81. DHCP is provided by dnsmasq, so this may account for the change in behavior.
https://pi-hole.net/2020/04/12/pi-hole-covid-19-and-a-special-easter-gift/#page-content