IPv6 PTR requests every ten seconds

[vincent]

I dont know why, but this command :

tail -n 100000 /var/log/pihole.log | grep 'query\[PTR\]' | grep 'from\ 127\.0\.0\.1$'

retrieve 1 ptr query every ten seconds from 00:00 (log recycle) to 13:53:45 and then nothing more.
While I was writing this message, I check again and the issue restart at 15:00:00 : every ten seconds up to now.

Dec  1 15:12:07
Dec  1 15:12:17
Dec  1 15:12:27
Dec  1 15:12:37
Dec  1 15:12:47
Dec  1 15:12:57
Dec  1 15:13:07
Dec  1 15:13:17
Dec  1 15:13:27
Dec  1 15:13:37
...

[DL6ER]

This doesn't seem to be coming from Pi-hole. Is it always the same PTR request? If so, for which IP address?

[vincent]

Dec  1 15:33:38 dnsmasq[670]: query[PTR] c.1.2.3.6.b.2.e.f.6.e.0.8.c.8.4.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:33:48 dnsmasq[670]: query[PTR] 7.2.f.0.6.0.c.d.c.4.f.3.c.d.c.e.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:33:58 dnsmasq[670]: query[PTR] 4.0.9.6.7.2.2.4.8.b.d.4.3.f.9.6.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:34:08 dnsmasq[670]: query[PTR] 9.b.a.f.3.4.8.4.9.f.a.e.0.f.4.e.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:34:19 dnsmasq[670]: query[PTR] 7.7.c.4.e.a.4.7.d.4.3.0.3.a.d.c.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:34:29 dnsmasq[670]: query[PTR] e.8.3.4.3.5.3.a.f.a.4.5.3.a.f.a.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:34:39 dnsmasq[670]: query[PTR] a.6.7.0.f.4.d.a.1.f.8.b.6.9.5.6.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:34:49 dnsmasq[670]: query[PTR] f.4.b.3.5.0.6.f.c.1.4.c.4.3.d.b.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:34:59 dnsmasq[670]: query[PTR] f.b.5.3.4.8.0.5.1.c.f.7.2.6.4.e.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:35:09 dnsmasq[670]: query[PTR] 6.9.c.d.9.6.4.4.6.5.5.d.9.a.8.2.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:35:19 dnsmasq[670]: query[PTR] 0.6.d.1.7.9.0.b.c.c.1.1.6.3.9.f.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:35:29 dnsmasq[670]: query[PTR] 5.c.c.b.5.0.3.c.7.0.2.5.b.4.e.9.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:35:39 dnsmasq[670]: query[PTR] b.f.e.0.6.c.0.6.5.a.a.6.f.e.4.7.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:35:49 dnsmasq[670]: query[PTR] b.b.3.2.d.3.f.1.5.f.6.e.9.4.0.f.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:35:59 dnsmasq[670]: query[PTR] c.d.9.8.5.5.8.3.7.5.1.9.2.9.b.2.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:36:09 dnsmasq[670]: query[PTR] b.3.5.7.0.f.3.c.6.6.4.e.1.5.9.d.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:36:19 dnsmasq[670]: query[PTR] 6.7.f.5.c.e.8.f.9.2.d.b.c.b.0.1.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:36:29 dnsmasq[670]: query[PTR] f.e.6.4.6.d.a.6.2.9.8.a.e.5.c.c.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:36:39 dnsmasq[670]: query[PTR] 5.4.2.3.1.5.8.f.1.2.2.3.0.4.0.7.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:36:49 dnsmasq[670]: query[PTR] 6.1.1.f.e.0.c.c.8.9.7.2.c.e.1.2.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:36:59 dnsmasq[670]: query[PTR] 9.7.6.7.5.5.e.7.4.3.e.8.3.e.0.5.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:37:09 dnsmasq[670]: query[PTR] c.f.1.e.6.e.0.3.0.f.c.b.d.3.8.e.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:37:19 dnsmasq[670]: query[PTR] 8.a.c.3.f.b.8.4.2.7.f.a.a.d.c.d.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:37:29 dnsmasq[670]: query[PTR] c.e.6.0.e.b.9.4.e.7.c.3.8.a.7.c.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:37:40 dnsmasq[670]: query[PTR] 9.1.d.d.b.c.4.d.4.8.f.a.c.8.d.c.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:37:50 dnsmasq[670]: query[PTR] 2.2.d.4.1.f.2.4.3.6.0.4.9.1.3.e.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:38:00 dnsmasq[670]: query[PTR] 107.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 15:38:10 dnsmasq[670]: query[PTR] 1.6.3.2.4.4.9.f.f.3.5.b.6.8.c.0.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1
Dec  1 15:38:20 dnsmasq[670]: query[PTR] c.b.6.b.4.2.6.1.9.d.0.0.c.d.0.a.0.a.0.A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa from 127.0.0.1

[DL6ER]

Can it be that one of your devices is using a new IPv6 address every ten seconds? This seems to be the only explanation as Pi-hole itself is doing PTR lookups only for clients and upstream servers.

Try setting

RESOLVE_IPV6=no

in /etc/pihole/pihole-FTL.conf followed by a

pihole restartdns

to tell FTL that you don't want host names for IPv6 addresses. This may not yet work in all cases, but we're looking at releasing a small update for this scenario in a few hours. Watch for FTL v5.3.2

[Bucking_Horn]

@vincent

(...).A.B.C.D.E.F.G.H.I.J.a.2.ip6.arpa

Those aren't valid IPv6 reverse domains (none are).

Are those indeed real queries as observed by you, or did you obfuscate them before posting?

[vincent]

@Bucking_Horn

obfuscate them before posting

yup

[vincent]

pihole restartdns

Restarting dns server solve the problem. With RESOLVE_IPV6=NO or YES, no more PTR queries flooding.
Some queries remains (both v4 and v6) but very few ; even though "never forward reverse lookups for priv IP range" is checked.

Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 123.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 123.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 130.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 130.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 88.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 88.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 10.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 10.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 124.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:09:00 dnsmasq[12027]: query[PTR] 124.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 123.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 123.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] b.f.5.e.0.0.d.a.b.a.3.d.7.f.9.b.A.B.C.D.E.F.G.H.I.J.0.a.2.ip6.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] b.f.5.e.0.0.d.a.b.a.3.d.7.f.9.b.A.B.C.D.E.F.G.H.I.J.0.a.2.ip6.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] f.0.d.a.3.7.6.6.d.7.e.7.3.c.d.b.A.B.C.D.E.F.G.H.I.J.0.a.2.ip6.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] f.0.d.a.3.7.6.6.d.7.e.7.3.c.d.b.A.B.C.D.E.F.G.H.I.J.0.a.2.ip6.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 130.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 130.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 88.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 88.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 10.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 10.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 124.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:15:00 dnsmasq[12437]: query[PTR] 124.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:25:00 dnsmasq[12437]: query[PTR] 146.1.168.192.in-addr.arpa from 127.0.0.1
Dec  1 16:25:00 dnsmasq[12437]: query[PTR] 146.1.168.192.in-addr.arpa from 127.0.0.1

[vincent]

From 15:00:00 to 15:48:53 : 278 ipv6 PTR queries -> 278 uniques ipv6 addresses
From 15:00:00 to 15:46:42 : 14 ipv4 PTR queries -> 10 uniques ipv4 addresses

I try to stop ipv6 resolution...

[vincent]

Thank you for your help @DL6ER

[vincent]

Aaaand... issue restart at 17:00:00 (both v4 and v6). Doesnt matter, I will wait for next release.
But maybe it's the same issue than "Pi-hole Reverse DNS queries every hour". For some users, it lasts few minutes ; for others, it's longer.

[DL6ER]

I agree that it may be the same issue. Until your last messages, I thought it's precisely doing one query for a different IP every ten seconds. That would have been something separate. I think that's still correct looking at the older posts, however, you are apparently also experiencing the other issue.

Have you already tried

Pi-hole Reverse DNS queries every hour

Anyone who want to try my idea can now run: pihole checkout ftl fix/hourly_PTR_requests and continue to monitor the PTR request spikes (hopefully, there are none). As mentioned above, I have the new option REFRESH_HOSTNAMES defaulting to IPV4. You can also try to switch to NONE to get completely rid of trying to resolve clients hourly. Any testing is highly appreciated as my local testings always only happen in a rather quiet network without any Windows or Apple devices. You can always use p…

?

[vincent]

I will try your solution but before, I want to purge the network_addresses table. One of my clients is registered in this table with 114 ip adresses !
From my understanding, FTL parse this table each hour and query ptr for each entry. I would like to see if, with a clean table (2 or 3 addresses per client), this process would be quicker.
Issue will still be there, but quicker.

[DL6ER]

@vincent

From my understanding, FTL parse this table each hour and query ptr for each entry.

Yes, this will also be improved on with said special branch.

[vincent]

After purge on the network_addresses table :
FTL still query PTR every hour at HH:00:00
1 PTR query every ten seconds
BUT the table contains now 60 rows (instead of 470) so PTR queries only run for 9 min maximum (instead of the whole hour, which overflow on the next hour, etc.).

Commands used to purge table :

logout from web admin interface
sudo systemctl stop pihole-FTL.service
pihole status //check if FTL is correctly stopped
sudo sqlite3 /etc/pihole/pihole-FTL.db "DELETE FROM network_addresses WHERE (ip LIKE '2a01:AAAA:BBBB:CCCC:%'  AND lastSeen < (SELECT strftime('%s','2020-12-01')));"
sudo systemctl start pihole-FTL.service

ip LIKE '2a01:AAAA:BBBB:CCCC:%'
-> only catch SLAAC addresses from router prefix advertised
-> exclude link local fe80::/10 and ipv4 addresses

lastSeen < (SELECT strftime('%s','2020-12-01'))
-> addresses seen before the first december (dont delete fresh addresses)