DNS resolving issues with Local DNS in custom.list

Expected Behaviour:

I should see a reply with 192.168.1.135, and not the public IP address starting with 65.

Actual Behaviour:

Oct 12 22:18:28 dnsmasq[2731]: query[type=65] nextcloud.chris.com from 192.168.1.130
Oct 12 22:18:28 dnsmasq[2731]: forwarded nextcloud.chris.com to 1.0.0.1
Oct 12 22:18:28 dnsmasq[2731]: query[A] nextcloud.chris.com from 192.168.1.130
Oct 12 22:18:28 dnsmasq[2731]: /etc/pihole/custom.list nextcloud.chris.com is 192.168.1.135
Oct 12 22:18:28 dnsmasq[2731]: validation result is INSECURE
Oct 12 22:18:28 dnsmasq[2731]: query[type=65] chris.ddns.net from 192.168.1.130
Oct 12 22:18:28 dnsmasq[2731]: forwarded chris.ddns.net to 1.0.0.1
Oct 12 22:18:28 dnsmasq[2731]: query[A] chris.ddns.net from 192.168.1.130
Oct 12 22:18:28 dnsmasq[2731]: forwarded chris.ddns.net to 1.0.0.1
Oct 12 22:18:28 dnsmasq[2731]: validation result is INSECURE
Oct 12 22:18:28 dnsmasq[2731]: reply chris.ddns.net is 65.<redacted>.150
Oct 12 22:18:28 dnsmasq[2731]: validation result is INSECURE

Debug Token:

https://tricorder.pi-hole.net/g9j734w6ws

Ok and? That doesn't explain why it found it in the custom.list, ignored the custom.list and then ended up using the upstream gateway anyways. Unless I'm missing the point you're trying to make.

Perhaps I misunderstood your problem statement. Please explain in some more detail. It's difficult to read your redacted log and tie this to the problem. Also provide the contents of your custom.list.

Pi-hole tends to [redacted] in that [redacted]. If you change [redacted] to [redacted] then you'll see that Pi-hole will [redacted].

Sorry I don't want to post my private information. I have a local DNS entry configured in the pi-hole interface, that also exists as a public DNS. When I hit it locally I want the private IP and not the public IP. When I navigate locally it tries to resolve using the upstream gateway which is my Public IP.

/etc/pihole/custom.list nextcloud.domain.com is 192.168.1.135 - local IP I want it to reply with

nextcloud.domain.com has a CNAME to domain.ddns.net publicly

reply domain.ddns.net is 65.30.2.150 - it's replying with Public IP that I don't want locally

I want my public IP externally when I navigate to nextcloud.domain.com, but when internal, I want nextcloud.domain.com to use the internal address specified in the Local DNS under pi-hole.

I'll try to put it in a different way:

You likely only have defined a custom DNS record for [redacted].
But from a DNS perspective, your query is for a different name:

In order for that FQDN to be resolved locally, you'd also have to define the respective local DNS record for [redacted].ddns.net.

I updated my main post with actual domain name and IP information. I guess I'm confused. When I navigate to nextcloud.chris.com I want internal devices to resolve to 192.168.1.135. I assumed adding a "Local DNS" entry to the pihole that when I went to fetch DNS, it would find that there is an entry mapped in the custom.list on the pihole and reply with that internal address.

I guess I don't understand why it's reaching to the upstream gateway for nextcloud.chris.com, if it's finding it in the custom.list with an address of 192.168.1.135.

You likely only have defined a custom DNS record for nextcloud.chris.com.
But from a DNS perspective, your query is for a different name:

In order for that FQDN to be resolved locally, you'd also have to define the respective local DNS record for chris.ddns.net.

Is it possible that this happens for you with the Nextcloud app on iOS 14?

At least that's where I am running into this problem. I added a local DNS record for nextcloud.domain.tld but it started to have connectivity issues. The log from Pihole is as follows:

query[type=65] nextcloud.domain.tld from 192.168.1.137
forwarded nextcloud.domain.tld to <provider DNS IP>
query[A] nextcloud.domain.tld from 192.168.1.177
/etc/pihole/custom.list nextcloud.domain.tld is 192.168.1.100

In the UI it shows up as "OTHER". I believe that this (query[type=65] forwarded to the external DNS) causes the connection to fail.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.