Manual DNS working on and off?

Help
1

Hi - having an issue where manual created DNS entries appear to work for 5 mins, then receive my public IP for 5 mins, and on and on...

Expected Behaviour:

Manual DNS entries created by using these instructions:

Should work as expected, all clients on the LAN can resolve DNS enquiries to static machines.

Actual Behaviour:

Looking in the logs of various machines on the network i see results like this: (IP addresses anonymized)

[2019-01-03 07:10:06] NOTICE[2020] dnsmgr.c: dnssrv: host 'my.domain.com' changed from 162.139.14.2:0 to 192.168.0.10:0
[2019-01-03 07:10:06] NOTICE[2020] dnsmgr.c: dnssrv: host 'my.domain.com' changed from 162.139.14.2:0 to 192.168.0.10:0

And then 5 mins later back to:

[2019-01-03 07:10:06] NOTICE[2020] dnsmgr.c: dnssrv: host 'my.domain.com' changed from 192.168.0.10:0 to 162.139.14.2:0
[2019-01-03 07:10:06] NOTICE[2020] dnsmgr.c: dnssrv: host 'my.domain.com' changed from 192.168.0.10:0 to 162.139.14.2:0

And so on, flip-flopping between DNS requests getting the correct static address, then getting my public IP address.

Thanks for any help

2

Please upload a debug log and post the token here.

3

Thanks - debug token is: ia71gj6ewq

4

Your debug log looks normal.

What was the original purpose of setting the manual DNS entries using that guide?

Is the problem you are seeing a recent problem (since you set up using the guide); or did you set it up per the guide, it worked well and then later developed a problem?

5

The original purpose is that i have some machines on the network that require split-horizon dns resolution (for services served both inside and outside the network).

EG server.domain.com is internally resolving to 192.168.0.4 whilst externally server.domain.com is resolving to my public IP.

Setup of pi-hole went smoothly, i then added the manual DNS with that guide and the issue started immediately.

Also on this pi is a ubiquiti controller - this handles all DHCP but DNS servers are handed out manually as the IP address of the pi. Primary DNS is the pi, secondary dns is 1.1.1.1

7

This is a problem to be solved with your network configuration. We can only give limited help here, as we deal with Pi-Hole issues primarily.

8

Thanks msatter

Yes hairpin would be a good solution - but the reason i am not doing it is that i have some services running on the same subdomain but a different port that i am not opening up to the internet (because i just use it locally) and if i use hairpin it will not be able to connect (as there would be no port-forward)

EG server.mydomain.com is a webserver at port 80 and has a forward rule at the router.

But server.mydomain.com:8443 is a config page for that server and i don't want to open up 8443 to the internet as i only configure locally. With hairpin, 'server.mydomain.com:8443' won't go anywhere as there is no port forward.

Anyway thanks for the suggestion and i will look further into it!

9

Totally understood - i thought the behavior was unusual and as pi-hole is running dnsmasq this would be the right place to ask.

10

You are right. However, problems that go down so deep into the guts of dnsmasq should rather be discussed on the dnsmasq-discuss mailing list where the developer of dnsmasq (Simon Kelley) can directly respond and provide potential bug fixes.

11

Great! Thanks for the recommendation DL6ER - i will ask there.

12

SOLVED

To follow up in case anyone else is in a similar position.

This was down to my router handing out a secondary DNS server (1.1.1.1). My best guess is that any delay in the pi-hole resolving an address and the query went onto the cloudflare dns.

So in this case, making sure the router was only handing out a primary DNS server (the pi-hole) solved the issue.

14

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