I'm running a Pi-Hole on a raspberry pi on my local network. I also have another device running a nextcloud instance on that same network. I have set it up so that I can access that nextcloud instance remotely (say, via cloud.example.com), but I'd like, when I'm on my local network, for cloud.example.com to point to the local ip address of the nextcloud device.
Actual Behaviour:
I set up a local DNS entry to try to do this, but when I ping cloud.example.com it's clear that it's accessing it through the WAN address, not the local network. So clearly the local DNS is not taking priority somehow. On the other hand, if I add a local DSN entry cloud.example.local, and ping it, it works perfectly, pointing to the local address.
How can I make the local DNS take priority, so that I access the cloud.example.local through the local IP address when I'm home?
When I go to the browser interface, under LocalDNS>DNS records, there are two records listed. (But there should have been one before, I would think...)
My bad - I see now that your debug log was created by an earlier version of Pi-hole, where custom definitions were not yet present (you'd need at least Core v5.7, and you are on Core v5.6).
Could you share a screenshot of those definitions?
Your debug log shows that your network has public IPv6 connectivity.
IPv6-capable clients would prefer IPv6 over IPv4, and since you've defined only an IPv4 address so far, such a client may use the public IPv6 instead.
You should consider to create an entry for an IPv6 address as well.
If you were indeed still seeing the public IPv4 address used by ping, your client may still have been caching the IPv4 adress until its TTL expires. This may be the most likely explanation for your observation.
Please also note that ping isn't an adequate tool to analyse DNS issues, as it uses additional means beside DNS to resolve hostnames. Use dig or nslookup instead.
And even if not related to your observation, you should also be aware that .local is reserved for use by the mDNS protocol (one of the aforementioned additional means) and shouldn't be used with DNS.
And finally, please note that while plain DNS may provide the expected results, other protocols may still disagree with shadowing a public domain, e.g. you could expect to see certificate errors when accessing a shadowed domain's website via HTTPS.
