Expected Behaviour:
Pi-hole is trying to reverse lookup every IP address on my subnets. I expect that there's a way towhite list those sub-nets so they don't get a reverse lookup.
Actual Behaviour:
Pi-hole is trying to reverse lookup every IP address on my subnets.
Question:
How can I tell Pi-hole not to reverse lookup IP ranges?
I read that this is controlled by dnsmasq settings but, there are no dnsmasq settings and it looks like dnsmasq isn't even running. /etc/dnsmasq does not exist, /etc/dnsmasq.d is empty.
I see many questions on this topic but no answers as to how to set IP ranges to not reverse lookup.
Change the following parameter in file /etc/pihole/pihole.toml to true to enable additional dnsmasq configuration files:
# Should FTL load additional dnsmasq configuration files from /etc/dnsmasq.d/?
# Warning: This is an advanced setting and should only be used with care.
# Incorrectly formatted or config files specifying options which can only be defined
# once can result in conflicts with the automatic configuration of Pi-hole (see
# /etc/pihole/dnsmasq.conf) and may stop DNS resolution from working.
etc_dnsmasq_d = false
Can you provide some examples from your dnsmasq log at /var/log/pihole/pihole.log showing some of the PTR queries and replies?
Reverse lookups are both legit and common.
As you've observed, Pi-hole itself would issue them once every hour, so your Query Log may show names instead of just client IPs.
Because I have hundreds of devices on my local network and I didn't bother to add DNS/hosts entries for them because I know what they are by IP.
Pi-hole is generating alot of extra traffic trying to look up these devices.
If it's on my sub-net, I don't need/want a reverse lookup because I already know what it is by IP.
For example, I know exactly what 10.1.2.44 is, I don't need that looked up: 44.2.1.10.in-addr.arpa 30hits
This one certainly isn't needed: 1.0.0.127.in-addr.arpa
jfb, if I read some of your previous posts correctly, I shouldn't be having this issue because I have enabled:
Never forward reverse lookups for private IP ranges
All reverse lookups for private IP ranges (i.e., 192.168.0.x/24, etc.) which are not found in /etc/hosts or the DHCP leases are answered with "no such domain" rather than being forwarded upstream. The set of prefixes affected is the list given in RFC6303.
This is unusual. My dnsmasq log (with no abnormal traffic) shows all the DNS queries, forwards and replies (including PTR). Have you changed your logging defaults?
You know, I didn't think of that. It may NOT be the pi-hole doing the reverse lookups. I just wiped the tables so I need to wait for another arpa lookup to see what device is requesting it...
UPDATE: Welp, I just turned on my work [windows] laptop and it's FLOODING the table with traffic. I'll have to wait until tomorrow to turn it off and wipe the tables to check those lookups.
Ah, so your request is about those reverse lookups that Pi-hole itself issues.
If it would really be Pi-hole's hourly reverse lookups, you could use the following options to control that:
# With this option, you can change how (and if) hourly PTR requests are made to check
# for changes in client and upstream server hostnames.
#
# Possible values are:
# - "IPV4_ONLY"
# Do hourly PTR lookups only for IPv4 addresses. This is the new default since
# Pi-hole FTL v5.3.2. It should resolve issues with more and more very
# short-lived PE IPv6 addresses coming up in a lot of networks.
# - "ALL"
# Do hourly PTR lookups for all addresses. This was the default until FTL
# v5.3(.1). It has been replaced as it can create a lot of PTR queries for those
# with many IPv6 addresses in their networks.
# - "UNKNOWN"
# Only resolve unknown hostnames. Already existing hostnames are never refreshed,
# i.e., there will be no PTR queries made for clients where hostnames are known.
# This also means that known hostnames will not be updated once known.
# - "NONE"
# Don't do any hourly PTR lookups. This means we look host names up exactly once
# (when we first see a client) and never again. You may miss future changes of
# host names.
refreshNames = "IPV4_ONLY"
You should probably only consider resolver.refreshNames if IP adresses are uniformly assigned to clients in your network, which implies that you know your clients.
If random clients join your network (e.g. when offering a wifi hotspot in a coffee shop), then you may consider to switch off Pi-hole's reverse lookups altogether:
# Should FTL try to resolve IPv4 addresses to hostnames?
resolveIPv4 = true
# Should FTL try to resolve IPv6 addresses to hostnames?
resolveIPv6 = true
So, I have played with it more and here's what I have learned... MOST of those PTR queries were coming from a Mint machine I have running and they were being generated by networkmanager.
After adding "dns=no" to the networkmanager file, they all went away (from that machine).
Now, I'm still getting PTR lookups from the Pi-hole itself and I assume that it's networkmanager again.
If I add:
[main]
dns=no
...to the Pi-hole's networkmanager config file will it break Pi-hole?
Does Pi-hole use networkmanager for DNS lookups or does it soley rely on DNSmasq?
Bucking_Horn - I think I understand what you're saying and if I understand it, I don't think it's the solution I'm looking for.
My devices [mostly] don't have DNS names so they will never resolve in the first place so it sounds like (to me) that resolver.refreshNames won't work.
I also don't want to totally disable PTR lookups because, it's nice to see spyingonu.microsoft.com in the reports and not 123.321.23.33.
What I really want is to add 10.1.0.0/16 to a file somewhere and have PTR lookups not done on that subnet.
I thought about just adding the IPs to /etc/hosts but, that's going to be really messy.
I do think resolver.resolveIPvX are exactly what you're looking for, as those will only impact PTR lookups Pi-hole itself sends to associate IPs with local hostnames.
EDIT:
It will stop Pi-hole's own hourly PTR lookups, but won't affect reverse lookups by clients (including those by the machine that Pi-hole's runs on).
For clients issuing excessive PTRs, you'd have to address those clients individually, as you've done with your Mint OS client.
Bucking_Horn - This is all new to me and you certainly know more about this than I do so, let me try your suggestion and report back any changes. Thanks
Never forward reverse lookups for private IP ranges
