In your case, it would show up, as you've confgured your host to use itself (127.0.0.1) for DNS, i.e. your Pi-hole on that machine.
Unrelated to your issue, you may want to add a public DNS server as well, so you can still run updates and repairs if Pi-hole should be inoperational for any reason.
Change your dhcpcd.conf to read similar to:
static domain_name_servers=127.0.0.1 1.1.1.1
Substitute 1.1.1.1 with a public DNS resolver of your choice.
Still unrelated to your issue, but you should also remove the duplicate definitions from that file, i.e. the last three lines from yolur above output.
Regardless of using unbound or other upstreams, it's worth considering.
You've manually added that to your Pi-hole configuration.
As we couldn't find out about the client that causes those requests, we may shift our focus from finding the offender to just trying to mitigate those warnings instead.
You have a couple of options for that:
- add the domains triggering the warning to Pi-holes block list
-- u.mokexapp.co
-- u.mokexapp.cloud
-- u.mokexapp.club - add
rebind-localhost-okto your custom config at/etc/dnsmasq.d/pi.conf - delete your custom
stop-dns-rebindat/etc/dnsmasq.d/pi.conf
rebind-localhost-ok would allow 127.0.0.1 as an answer, so would work for other domains as well. Although that should still be considered an illegit answer by an upstream, it's reasonably safe to allow, as the localhost address points to the machine that issues the request.
I'd try them in the order I've listed them, and probably would opt for a combination of 1 and 2.