host-records are not used after some time

Hello community.

I have started using pi-hole as my local DNS. I have a router, which acts as DHCP server for several VLANs, and I want to keep it this way (don't want DHCP by pi-hole). Router also assigns the search domain to all clients (example.com).
For my some of my local hosts, servers, etc. I have static IPs assigned. For these, I have created a conf file in /etc/dnsmasq.d/ directory, which contains a list of --host-record directives, e.g.:
--host-record=ilo,ilo.example.com,10.201.25.2
--host-record=xcpng,xcpng.example.com,10.201.25.3
--host-record=syno412,syno412.example.com,10.201.25.5

I have also defined 2 other hosts through GUI's local DNS option:
hostA.example.com 10.201.22.20
hostB.example.com 10.201.22.21

pi-hole is the only DNS server assigned to all DHCP clients.

Expected Behaviour:

All clients should be able to resolve names from either --host-records or LocalDNS as local IP addresses.

Actual Behaviour:

The expected behaviour works for some time.
After certain time when I try to resolve hosts from --host-record list, pi-hole does not return internal IPs, but queries external DNS servers and returns my public IP (returning external IP in this case is correct considering that external DNS servers are asked, as they are configured this way, but this behaviour of pi-hole is not desired/expected).

If I query HostA or HostB, I get correctly the local IPs.

If I play around in GUI (probably triggering some reload) or if I simply restart the DNS service via GUI, then I get again correct resolution to local IPs also for --host-records for some time.
So to me it looks like the --host-records time-out after some period and pi-hole forgets them unless reloaded.

If it matters:

  • Interface options = permit all origins
  • Never forward non-FQDN A and AAAA queries = checked (useless[?] since clients have search domain assigned?)
  • Never forward reverse lookups for private IP ranges = checked
  • Use DNSSEC = unchecked
  • DHCP server = disabled

The behaviour has been confirmed from various clients, i.e. not only my laptop, but also other VMs and hosts cannot resolve local names provided via host-record after some time.

Debug Token:

I would have included the token, but the script has been hanging on this line for the last hour:
-rw-r--r-- 1 root root 12M Dec 22 00:00 /etc/dnsmasq.d/dnsmasq.adlist.conf
But given that the bash is utilising the CPU the most, maybe it is still doing something. I let it run a bit longer and if it finishes, I'll post the token.

Run from a client that cannot resolve ilo, please share the output of:

nslookup pi.hole
nslookup flurry.com
nslookup ilo

For the latter two, how do they register in Pi-hole's Query Log?

Hello.
Thank you for coming back to me.
Here are the results:

nslookup pi.hole
Server:		10.201.25.9
Address:	10.201.25.9#53

Name:	pi.hole
Address: 10.201.25.9
nslookup flurry.com
Server:		10.201.25.9
Address:	10.201.25.9#53

Name:	flurry.com
Address: 0.0.0.0

I didn't use ilo, because at this moment it resolves fine. However another host (zalohy) is failing.

nslookup zalohy
Server:		10.201.25.9
Address:	10.201.25.9#53

Non-authoritative answer:
Name:	zalohy.example.com
Address: 88.212.X.Y (my public IP)

The corresponding entry in dnsmasq.d/ config file is this:
--host-record=zalohy,zalohy.example.com,10.201.25.25

In the log (I hope copy/paste is readable):
|2024-12-22 19:35:12|A|zalohy.example.com|10.201.22.99|OK (cache)|IP (0.8ms)||
|2024-12-22 19:35:03|A|zalohy.example.com|10.201.22.99|OK (answered by dns.opendns.com#53)|IP (63.5ms)||

2024-12-22 19:34:22 A flurry.com 10.201.22.99 Blocked (gravity) IP (1.7ms)

Note: to be honest, all other entries I have tried (about 10 of them) resolve ok at this time, so I am glad we've got at least one that's causing trouble.

Thank you.
B.

Your Query Log shows that the request for zalohy.example.com has indeed been forwarded upstream, but expansion of zalohy seems to have happened on the client.

As the debug log is missing, I can't attempt an explanation as to what configuration options may contribute to your issue.

However, you should be able to prevent requests for *.example.com from ever being forwarded upstream by adding the following line to your custom dnsmasq configuration file holding your host-records:

local=/example.com/

Note that doing so would also cut you from being able to request public resulotion for *.example.com.

Thank you for your suggestion. I will try that. If it does not help, I will probably move to using the custom.list file which seems not to cause issues.

The reason I used host-records was to have the PTR automatically generated, which (recalling way back) were perhaps required for mail server for example. But since I am using packaged solutions now, perhaps it's not an issue.

Nevertheless, I read on the forum that developers are working on new version, so instead of troubleshooting this one, let's keep them focus on the new version and we will see there.

Thank you.
B.

PS: as for the debug log - the script never finished. I noticed cursor blinking under the line I mentioned above, so it looked like it is maybe expecting some input. I could type, press Enter, etc. but did't help. I had to terminated with CTRL+C. I think 2 hours for a 12MB file was enough, right? :slight_smile: Merry Christmas everyone.