Exclude local domains from top domains

I'm using Pi-Hole with Unbound as DNS and my fritzbox as DHCP.
Works as expected.

What I do encounter as I start to switch from IP-based local adresses to FQDNs (aka HOSTNAME.fritz.box), that those requests do get into my "top domains" dashboard statistics.

I filled in the "fritz.box" in my local domain settings:

Should then the "local permitted domains" be excluded from the statistics?

I read the following, which is a bit old and refers to an old version of Pi-Hole:

Is it still "the way"? or are there other configurations in place, if I don't want local domains (which should be permitted anyways) to show up in my dashboard?

What switch are you referring to?
Some switch in Pi-hole's UI?
I'm not sure I understand what you tyring to describe here.

A few actual examples of those observed requests may help.

Sorry, i meant instead of "192.168.78.10" I started to use "openhabmain.fritz.box". I meant "me - switching to not remember IP-addresses anymore" :wink:
And then I'll get this, which kind of scrambles my dashboard, because local domains should always be "permitted" I guess?
grafik

(1) this is an external domain (for my Niu e-scooter API)
(2) these are internal devices/servers, which I use throughout my local network

I guess this would involve using names instead of IP addresses in third-party software configuration?

Pi-hole wouldn't stop you from blocking local domains.
So more generally, your sentence becomes: Permitted domains should always be permitted. :wink:

If in the past your clients were referring to certain servers/services by IP address, but are configured to do so by name now, then Pi-hole's dashboard reflects DNS resolution requests as they happen in your network.
They still may be excessive, i.e. happening more often than they'd have to.

If a client would lack or ignore a local DNS cache (as maintained by that client machine's OS), the client may excessively request resolution.
In such a case, it would make sense to either enable a client's DNS cache or to use IP addresses instead in order to avoid unnecessary DNS requests.

But even if the client would correctly cache a DNS reply, it would do so only for the duration of its TTL. If the TTL is low, that may also prompt a client to repeat DNS requests.

In your case, I'd expect TTLs for local domains to be controlled by your FritzBox router, as you've enabled Pi-hole's Conditional Forwarding. My own FB is using a local TTL of 10 seconds, which is a sensible value.

But in case some of your Local DNS Records are held by Pi-hole, we should also check your Pi-hole's local TTL setting:

Run from your Pi-hole host machine, what's the output of:

grep -nR local-ttl /etc/dnsmasq.d*

If that comes back empty, that would imply a local TTL of zero, and you may want to consider adding it via a custom configuration file.

And last not least, if you cannot control those requests otherwise, you may filter them from appearing in the dashboard via Settings | API / Web interface.

thanks for your explanations!

yes, e.g. I use local APIs for my smarthome devices, and my smarthome hub (openhab.org) checks mobile phones for presence detection and all

it's empty indeed.

I only added here the DNS for a "local" NAS, which is connected via a LAN-LAN VPN so I need this FDQN with the remote LAN-IP, otherwise it's empty.

How can I configure the FritzBox' TTL? I don't think that's possible with AVM FritzOS?

ok, that's ok, if there's no configuration to blindly allow all local DNS. There's no wildcards possible in this setting?

I am unaware of any respective option for the FB router, but that would be a good question for AVM support.

Note that we have not yet established whether local TTLs would be related to your observation.

If there's only one local DNS record, I doubt you'd address your original issue by adding a local-ttl then, but still:
You could create a custom file like /etc/dnsmasq.d/42-local-ttl.conf and add

local-ttl=20

Afterwards, run pihole restartdns.

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