Not sure what to make of this? Just strikes me as odd at seeing a local address trying to gain access from outside? or is this a fluke. If anything I just want to make sure I didn't good anything up.
Recently I did upgrade my router to RT-AX88U Pro running merlin firmware 388.3 "https://www.asuswrt-merlin.net"
I know the router isnt in your neck of the woods, but on this router firmware, I wont get DNSSEC unless I "Enable DNSSEC support" is checked. I thought "UNBOUND" took care of that. but if I don't have that enabled, it will fail DNSSEC validation. "https://internet.nl"
With the address being a private one, ie 192.168..., this is often seen when a machine boots, or wakes up from suspend, with a VPN enabled (if this was indeed a host from outside trying to gain access you would see a public IP address).
Just before the VPN is established, or re-established, the network interface with that unknown address will be using the Pi-hole just like the rest of the machine is. Once the VPN link is up, it uses the DNS on the VPN service instead and doesn't bother the Pi-hole anymore. It can happen for example with a work laptop when it's booted up, just before it connects to the corporate VPN.
Since Pi-hole defaults to only allowing local requests (in your case that's 192.168.1...) it flags it up as "non-local". The warning page shows the date and time it happened so if you can remember what was going on then it might help work out what caused it.
Alternatively you can safely delete the warning and see if it happens again, and note the time it happens and try to tie it in with something, maybe a work computer or a friend visiting who has previously jumped on your network, and their phone has a VPN app running. You could try pinging the IP and seeing if it responds. It may be related to some capability that your router has.
The DNSSEC settings on your router apply to the DNS server running on your router (on 192.168.1.1). If something uses the router for DNS then it will have that DNSSEC protection.
In your case your Pi-hole (with Unbound) is your DNS server (on 192.168.1.3) and the router is giving out this IP address for clients to use for their DNS. Unbound is always doing DNSSEC so you are protected. If you want to see this DNSSEC info from Unbound you can enable Settings > DNS > Use DNSSEC then Save in Pi-hole and it will show an extra row in the Query Log for the DNSSEC results.
A couple of extra points.
First, your router's DHCP is also giving out address 192.168.1.4 as a second DNS server to use. If you want everything to use your Pi-hole then you will have to remove that from the router's DHCP settings so it is not being given out.
Second, if you are finding that you still need to have the DNSSEC option on in the router for the tests to say it's enabled, it implies that the client that you're testing from is using the router for DNS. Since the router's DHCP is not giving itself out as a DNS server to use, that implies the client's DNS has been manually set to use the router. Worth checking if this happens.
From Pi-hole's point of view, only those IP subnets attached to its host's network interfaces are considered local.
Your debug log suggests that to be 192.168.1.3/24 only in your case.
In addition to chrislph's musings, you may see other private addresses if your network would make use of VLANs, or if you would host your Pi-hole on some virtualised environment.
If that would be the case, you may have to adjust Pi-hole's interface listening behaviour to actually allow Pi-hole to process DNS traffic from those origins.
