I'm running the latest version of Pi-Hole on a RaspPi 3 and since configuring my router to direct certain clients to Pi-Hole I'm getting a lot of reverse-DNS lookups (PTR) in Query Log. I also have conditional forwarding enabled in the Pi-Hole's DNS settings.
I read something that suggested making Pi-Hole only list A and AAA queries by editing the FTL config file but that seemed to just disable logging completely, so I've now reverted the conf file back to what it was previously, and rebooted the Pi.
I've also disabled the avahi service as I also read that can cause excessive PTR traffic, have verified that the service isn't running, but that's had no impact.
Can anyone suggest why I'm getting the PTR entries in query log?
Excessive PTR queries can be caused by conditional forwarding generating a loop. Client asks for PTR, goes to Pi-hole, goes to router, back to Pi-hole, etc.
Please show some PTR queries, forwards and replies from your dnsmasq log at /var/log/pihole.log. This will help us diagnose the flow path.
Feb 16 11:32:59 dnsmasq[570]: using nameserver 192.168.1.1#53 for domain home.lan
Feb 16 11:32:59 dnsmasq[570]: using nameserver 192.168.1.1#53 for domain 1.168.192.in-addr.arpa
Feb 16 11:32:59 dnsmasq[570]: using nameserver 212.159.13.50#53
Feb 16 11:32:59 dnsmasq[570]: using nameserver 212.159.13.49#53
Feb 16 11:32:59 dnsmasq[570]: read /etc/hosts - 5 addresses
Feb 16 11:32:59 dnsmasq[570]: read /etc/pihole/custom.list - 0 addresses
Feb 16 11:32:59 dnsmasq[570]: read /etc/pihole/local.list - 2 addresses
Feb 16 11:33:01 dnsmasq[570]: query[PTR] 148.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 11:33:01 dnsmasq[570]: forwarded 148.1.168.192.in-addr.arpa to 192.168.1.1
Feb 16 11:33:01 dnsmasq[570]: reply 192.168.1.148 is Gateway17161E.home.lan
Feb 16 11:33:01 dnsmasq[570]: query[PTR] 81.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 11:33:01 dnsmasq[570]: /etc/pihole/local.list 192.168.1.81 is raspberrypi3
Feb 16 11:33:01 dnsmasq[570]: query[PTR] 1.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 11:33:01 dnsmasq[570]: forwarded 1.1.168.192.in-addr.arpa to 192.168.1.1
Feb 16 11:33:01 dnsmasq[570]: reply 192.168.1.1 is RT-AC68U-EE28.home.lan
Feb 16 11:33:01 dnsmasq[570]: query[PTR] 50.13.159.212.in-addr.arpa from 127.0.0.1
Feb 16 11:33:01 dnsmasq[570]: forwarded 50.13.159.212.in-addr.arpa to 212.159.13.50
Feb 16 11:33:01 dnsmasq[570]: forwarded 50.13.159.212.in-addr.arpa to 212.159.13.49
Feb 16 11:33:01 dnsmasq[570]: reply 212.159.13.50 is cdns02.plus.net
Feb 16 12:00:00 dnsmasq[570]: query[PTR] 148.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 12:00:00 dnsmasq[570]: forwarded 148.1.168.192.in-addr.arpa to 192.168.1.1
Feb 16 12:00:00 dnsmasq[570]: reply 192.168.1.148 is Gateway17161E.home.lan
Feb 16 12:00:00 dnsmasq[570]: query[PTR] 81.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 12:00:00 dnsmasq[570]: /etc/pihole/local.list 192.168.1.81 is raspberrypi3
Feb 16 12:00:00 dnsmasq[570]: query[PTR] 1.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 12:00:00 dnsmasq[570]: forwarded 1.1.168.192.in-addr.arpa to 192.168.1.1
Feb 16 12:00:00 dnsmasq[570]: reply 192.168.1.1 is RT-AC68U-EE28.home.lan
Feb 16 12:00:00 dnsmasq[570]: query[PTR] 50.13.159.212.in-addr.arpa from 127.0.0.1
Feb 16 12:00:00 dnsmasq[570]: cached 212.159.13.50 is cdns02.plus.net
Feb 16 13:00:00 dnsmasq[570]: query[PTR] 81.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 13:00:00 dnsmasq[570]: /etc/pihole/local.list 192.168.1.81 is raspberrypi3
Feb 16 13:00:00 dnsmasq[570]: query[PTR] 1.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 13:00:00 dnsmasq[570]: forwarded 1.1.168.192.in-addr.arpa to 192.168.1.1
Feb 16 13:00:00 dnsmasq[570]: reply 192.168.1.1 is RT-AC68U-EE28.home.lan
Feb 16 13:00:00 dnsmasq[570]: query[PTR] 50.13.159.212.in-addr.arpa from 127.0.0.1
Feb 16 13:00:00 dnsmasq[570]: cached 212.159.13.50 is cdns02.plus.net
Feb 16 14:00:00 dnsmasq[570]: query[PTR] 1.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 14:00:00 dnsmasq[570]: forwarded 1.1.168.192.in-addr.arpa to 192.168.1.1
Feb 16 14:00:00 dnsmasq[570]: reply 192.168.1.1 is RT-AC68U-EE28.home.lan
Feb 16 15:00:00 dnsmasq[570]: query[PTR] 1.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 15:00:00 dnsmasq[570]: forwarded 1.1.168.192.in-addr.arpa to 192.168.1.1
Feb 16 15:00:00 dnsmasq[570]: reply 192.168.1.1 is RT-AC68U-EE28.home.lan
Feb 16 16:00:00 dnsmasq[570]: query[PTR] 1.1.168.192.in-addr.arpa from 127.0.0.1
Feb 16 16:00:00 dnsmasq[570]: forwarded 1.1.168.192.in-addr.arpa to 192.168.1.1
Feb 16 16:00:00 dnsmasq[570]: reply 192.168.1.1 is RT-AC68U-EE28.home.lan
Feb 16 16:00:20 dnsmasq[570]: query[A] tccprod01.honeywell.com from 192.168.1.148
Feb 16 16:00:20 dnsmasq[570]: forwarded tccprod01.honeywell.com to 212.159.13.50
Feb 16 16:00:20 dnsmasq[570]: forwarded tccprod01.honeywell.com to 212.159.13.49
Feb 16 16:00:20 dnsmasq[570]: reply tccprod01.honeywell.com is 199.62.84.151
192.168.1.148 is a wifi-connected thermostat for the home heating, 192.168.1.81 is the Pi-Hole host
I wouldn't call 1 query every hour to be excessive. If you want the Pi-hole interface to display the domain name instead of IP address for clients then you'll have to accept the fact that it will query once an hour to get the domain name of the IP address.
With this option, you can change how (and if) hourly PTR requests are made to check for changes in client and upstream server hostnames. The following options are available:
REFRESH_HOSTNAMES=IPV4 - Do the 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.
REFRESH_HOSTNAMES=ALL - Do the hourly PTR lookups for all addresses This is the same as what we're doing with FTL v5.3(.1). This can create a lot of PTR queries for those with many IPv6 addresses in their networks.
REFRESH_HOSTNAMES=UNKNOWN - Only resolve unknown hostnames Already existing hostnames are never refreshedi, 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.
REFRESH_HOSTNAMES=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.
If the log snippet that you posted is the actual full log then you don't really have clients using Pi-hole for DNS. There are no other queries except the PTR queries and the single WiFi Theromstat.
Well that's the odd thing - only my smart TVs and media streamers use Pi-Hole, or at least are configured to using the DNS filter facility on my Asus router:
There is no other reference to the Pi-Hole server (192.168.1.81) anywhere else in my router config, so I'm surprised that I'm getting PTR traffic from the Pi-Hole for devices that shouldn't be asking Pi-Hole to resolve a DNS request.
I'm guessing that's the thermostat and the router. (Or the thermostat and Pi-hole itself).
There's 3 clients configured in the settings, but those are manually added:
*** [ DIAGNOSING ]: Clients
id group_ids ip date_added date_modified comment
---- ------------ ---------------------------------------------------------------------------------------------------- ------------------- ------------------- --------------------------------------------------
1 2 74:A7:EA:BB:FB:E6 2021-02-15 18:15:55 2021-02-15 18:16:51 Amazon Fire Stick
2 2 84:C0:EF:47:5B:23 2021-02-15 18:16:36 2021-02-15 18:16:55 Samsung TV
3 2 54:BD:79:01:C8:53 2021-02-15 18:17:23 2021-02-15 18:17:31 Samsung TV (kitchen)
Going from the log snippet, there's only 1 A record query in 5 hours, which makes the hourly PTR records appear to be the dominant queries. When Pi-hole is handling the DNS for the network and is getting hundreds to thousands of A/AAAA queries an hour then the PTR records become trivial background noise.
If you check the Tools > Network page of the admin interface then I think you'll see why the PTR records happen. Pi-hole asks for the domain names of all the devices on the network segment, and shows you which ones are using Pi-hole and which ones are not. This is a diagnostic tool and may help you see what it happening on your network.
Thanks. There another FTL config setting ANALYZE_ONLY_A_AND_AAAA which when I add to pihole-FTL.conf seems to just kill the query log, with nothing ever appearing once ANALYZE_ONLY_A_AND_AAAA=true is added to the conf file
The device at 192.168.1.66 has it's IP manually assigned by the router, the other devices have theirs dished out by the router's DHCP server. I'm surprised that the Pi-Hole see's any devices other than the router and the RaspPi3, which the Pi-Hole obviously should know about.
Hello, I have a follow up question about PTR requests... what is 'normal' and what is 'excessive'?
I have lb._dns-sd. or variations of it filling 4 of the top 10 permitted domains (See screenshot below). It also seems like they always result in NXDOMAIN or N/A replies (Other when the pihole itself is querying in which case it gets a reply of DOMAIN). Is that ok? (See screenshot below). I know i can hide those from the 'Top Lists' area in settings, but before I do, I wanted to make sure that this was an acceptable amount of queries and that I don't have an issue I need to troubleshoot first.
They originate from two different iPhones, localhost, google home mini, mac mini etc... but the iPhones are definitely the largest source of the queries.
Today (as of 4:30pm) I've had 5,057 PTR queries out of my total 43,576. (1,749 are from one iPhone, and 2,706 are from the other.)
Pihole is my DHCP and I don't have Conditional Formatting on. I do have the three options in Advanced DNS Settings checked, and I'm running cloudflared with IPV4 only. This is running on a RaspberryPi.
If this is all normal then great, but if something is going wrong here, I'd appreciate knowing (and possibly help troubleshooting).
I'm obviously still learning but have learned a lot from you guys.
