After upgrading to 4.1.1 from 4.0.0 (I think), I'm seeing tons of PTR look ups for private IP ranges even though the setting "Never forward reverse lookups for private IP ranges" is checked. They were not happening before from what I could tell.
This is a fairly large privacy leak and useless data and should be stopped. Anyone else seeing this after upgrading to 4.1.1?
Now to see if I can downgrade without breaking everything worse...
What you are seeing is a new feature in 4.1 that shows more types of query requests in the query log. v4.0 and earlier showed A and AAAA requests only. V4.1 and later show additional query types (SOA, PTR, etc.).
There is a configuration option that reverts to showing A and AAAA only as described in this section of the documentation. Set ANALYZE_ONLY_A_AND_AAAA=true.
The PTR queries are not a privacy leak - they've been there all along, but now they are shown in the query log. That setting only makes sure that PTR queries for private IP addresses do not get forwarded to upstream DNS servers.
Was not expecting this traffic to be forwarded. Is the response, "yes, this is expected and it's been there all along"? Because giving up your internal network subnet is not something most people want to do and will attract attacks if upstream DNS is out of their control. Also, I am sure Google will use this info for additional tracking and verification.
/var/log# grep forwarded pihole.log |grep 168.192
Dec 31 00:45:17 dnsmasq[511]: forwarded b._dns-sd._udp.0.222.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded db._dns-sd._udp.0.222.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded r._dns-sd._udp.0.222.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded dr._dns-sd._udp.0.222.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded lb._dns-sd._udp.0.222.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded b._dns-sd._udp.144.188.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded db._dns-sd._udp.144.188.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded r._dns-sd._udp.144.188.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded dr._dns-sd._udp.144.188.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded lb._dns-sd._udp.144.188.168.192.in-addr.arpa to 8.8.8.8
Dec 31 00:45:17 dnsmasq[511]: forwarded b._dns-sd._udp.0.2.168.192.in-addr.arpa to 8.8.8.8
I don't want to turn off PTR queries. I want to see legit lookups for non-local traffic. I just don't want my actual private ranges to be leaked to the upstream.
If this is the case, you shouldnât trust them with the rest of your DNS traffic. Using unbound as a local resolver may provide you greater privacy.
Please elaborate on this.
Are these queries originating from a Mac? These are DNS Service Discovery (DNS-SD) queries frequently associated with the Apple Bonjour service.
No Macs in the network.
What client is making the requests?
Usually involves leveraging other flaws, like rule injection in routers or simply to map networks when being targeted. There's others as well, but let's just say, "because reasons".
Windows 10. Services shows a Bonjour service running. Will stop it and see if that stops the requests.
Waits a minute... nope, something else (or in addition).
If an external attacker has access to your router, they will immediately know all the clients and IP mapping on your network.
Ok, so you're taking the view this is normal, live with it? Otherwise, let's stick to the problem at hand. I'm not going to get into every potential attack and reason, just trying to solve this one problem at a time.
I already know this is from Windows 10. I don't know the APPLICATION. In any case, I wouldn't look to stop the app but change dnsmasq behaviour.
Unfortunately, this guy asked for help 7 years ago for this exact problem and I don't see a resolution. 
It looks like SImon kind of gave up and considered it normal.
Since FTL 4.1.2 is using dnsmasq (currently at Rev 2.79 with some bug fixes included), then the behavior of FTL is dependent on how dnsmasq implements this feature. This is not a behavior that is changed by Pi-Hole.
Per "man dnsmasq" it behaves as follows:
-b, --bogus-priv
Bogus private reverse lookups. All reverse lookups for private IP ranges (ie 192.168.x.x, etc) which
are not found in /etc/hosts or the DHCP leases file are answered with "no such domain"
rather than being forwarded upstream. The set of prefixes affected is the list given
in RFC6303, for IPv4 and IPv6.
As noted previously, this is normal dnsmasq behavior and the reason it is now seen using Pi-Hole V4.1 is the display of additional query types. It has been happening on your network, you just didn't see it in the earlier version of Pi-Hole.
If you cannot stop the traffic at the source, and if you have concerns with your upstream DNS provider seeing this information, you can avoid that situation by using a local recursive resolver.
You may be able to block the traffic at the source with hosts file entries.
You misunderstand. This feature, --bogus-priv, is what I THOUGHT would prevent this traffic from being forwarded upstream, but it doesn't. The link from 7 years ago confirmed. It is how dnsmasq stops processing packets and they get forwarded on. Special for dns-sd.
My dhcp leases files are all 192.168.2.x. My /etc/hosts contains only 192.168.2.x IP's. Yet there are private subnets being forwarded upstream for both 192.168.2.x and others used on the network (VPN's, internal networks and such).
So the pihole exposes more crap going on our LANS that we had no idea, yet again. But this makes me think that dnsmasq is not the solution for certain networks.
If you were not using Pi-Hole, how would you be resolving DNS? Going straight to Google would be no different. They would see these PTR queries and more (i.e. regular reverse lookups not mapped in hosts or leases files).
This feature is unchanged in dnsmasq for at least the last seven years. It's not a Pi-Hole issue.
However, note that a new feature of Pi-Hole V4.1 did allow you to see this traffic leaving your network. Previously you did not see the traffic, so the new feature provided this information. In that regard, it did expose something, giving you greater visibility to your DNS traffic.
Yes, we are in agreement on both these points.
At this point, this thread could be closed with "no Change" or "Not a bug" or some such. Will look to solve this with firewall rules.
If you are experiencing the behaviour described by @timbo i.e seeing that reverse lookups for hosts in the private IP range are beeing forwarded to an upstream DNS server, please check if the /etc/resolv.conf for the host running the pihole / dnsmasq.
It should contain a nameserver entry pointing to the pihole itsself not to the upstream DNS server.
cat /etc/resolv.conf
nameserver <IP of pihole/dnsmasq server>
With this in place no reverse lookups are forwared to upstream servers anymore.
This address should be in addition to the localhost address of 12.0.0.1?
