Ok, so the DNS server listening on you host's 127.0.0.1 is indeed Pi-hole.
Your host machine can resolve flurry.com via 9.9.9.9, a public DNS resolver.
And your Pi-hole at 192.168.2.2 correctly blocks flurry.com as expected.
Let's see what happens when you ask Pi-hole to resolve google.com:
Option 15 signals an EDE error code, where an info-code of 8 stands for an error in DNSSEC validation (Signature Not Yet Valid).
Please check the time of your Pi-hole host machine.
The most common cause for DNSSEC related failures would be wrong time information on the computer it runs on. RPis would be especially prone to that, as they lack a batttery-backuped RTC, potentially leaving them off-sync after longer periods of power-downs, until they can update their time from an NTP server. And with DNSSEC enabled, they cannot do so, as they won't be able to resolve a time server name to an IP address.
Thanks again for your reply - I am a novice user and not exactly sure how to check or correct that. I tried 'time' and that gave me some weird milliseconds output so now I tried 'date'
root@raspberrypi:~# date
Wed 20 Apr 2022 10:54:45 PM EDT
It is wrong indeed - and this device was unplugged for most of the day yesterday while the Fiber technicians installed my new gigabit internet. Is there a way to make this thing automatically sync when it gets online? I will also google this now and see if I can figure out how to change it
Adjust actual time as appropriate for your location, and also make sure your RPi's time zone information is correct (check via raspi-config).
Raspberry Pi OS will try to sync when online, but as explained, that would fail if DNSSEC is enabled while the time is still wrong.
You could work around this by not using 127.0.0.1 (your DNSSEC enabled Pi-hole) as the resolver for your Raspberry Pi OS, or -provided your router supports acting as a local time server- by adding your router's IP to the list of time servers to be used by your RPi OS.
root@raspberrypi:~# raspi-config
Current default time zone: 'America/New_York'
Local time is now: Wed Apr 20 23:12:25 EDT 2022.
Universal Time is now: Thu Apr 21 03:12:25 UTC 2022.
I set the time zone to something similar to mine (Toronto), but the date is still wrong here
root@raspberrypi:~# timedatectl status
Local time: Wed 2022-04-20 23:14:33 EDT
Universal time: Thu 2022-04-21 03:14:33 UTC
RTC time: n/a
Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
I typed this, found in the guide about syncing time above and this is the output. Unlike in the guide, it doesn't say anything is synchronized and he doesn't explain in the guide what to do when it isn't.
I will try setting manually as per instructions above but was hoping to get something more accurate
I am not quite sure how to apply any of those changes unfortunately, but I will see if I can research "changing resolver for raspberry pi os" if that's what I should do? Will also google how to add time servers and see if I can add my router which would be 192.168.2.1 ?
NTP will only correct small time offsets. A day off is too much for NTP to account for.
First step is to use
sudo date -s '21 APR 2020 15:15:00
verify that with date again.
Once you are within about an hour of actual time then NTP will keep things in sync.
Raspberry Pi devices lack an onboard Real Time Clock so it is pretty important to never pull the power and make sure you always safely shut down the Pi when you need to turn it off.
I rebooted the entire device via the reboot command..
root@raspberrypi:~# date
Wed 20 Apr 2022 02:15:51 PM EDT
root@raspberrypi:~# ping google.com
ping: google.com: Temporary failure in name resolution
root@raspberrypi:~#
The date went back to yesterday, again! Even after manually setting it before a safe reboot! So now instead I should re-issue the date command then just try to restart Pi Hole itself?
Sorry I tried to edit the post to change it to a response to you but ended up having to delete it
root@raspberrypi:~# date -s '21 APR 2022 15:50:00'
Thu 21 Apr 2022 03:50:00 PM EDT
root@raspberrypi:~# ping google.ca
PING google.ca (172.217.1.3) 56(84) bytes of data.
64 bytes from iad23s25-in-f3.1e100.net (172.217.1.3): icmp_seq=1 ttl=115 time=5.45 ms
64 bytes from iad23s25-in-f3.1e100.net (172.217.1.3): icmp_seq=2 ttl=115 time=4.99 ms
64 bytes from iad23s25-in-f3.1e100.net (172.217.1.3): icmp_seq=3 ttl=115 time=5.60 ms
^C
--- google.ca ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 4.985/5.342/5.595/0.273 ms
root@raspberrypi:~#
WOW, it's alive again.. but will this now stay in sync from this point on ?! Is there anything I should be doing right now to either sync it / make sure it stays sync'ed ? I guess yanking the power cord yesterday is the reason it got so screwed up?
The long power-down period would have caused the time to be off by too much to be synced, as DanSchaper has explained.
It is easy enough to fix that by manually adjusting the system clock, but it's as easy to forget about that until it happens again.
The most reliable way to address this would be to fit your RPi with a battery-backuped RTC. They are reasonably inexpensive (my DS3231 was about 4 Euros).
As for the chicken-egg issue of syncing with an NTP server when DNSSEC is failiing due to incorrect time, it would be best to cut DNSSEC out of the picture for syncing the time.
Editing your dhcpcd.conf (e.g. as suggested by nprampage) would do just that, by having your Raspberry Pi OS use a public DNS server instead of Pi-hole, allowing it to sync even if the time is off.