Analysing excessive DNS PTR requests (from router)

hi there

Sorry firstly if this is covered elsewhere.

please feel free to link to stuff (i did look at "DNS requests random strings & excessive router DNS queries" but i'm not sure i'm in a position to change router firmware).

Basically have just moved to fibre, new ISP etc.

Went from a nice integrated router/modem/wifiAP to separates (grrr).

Currently have 9 networked devices / hosts (wifi or cabled) incl a VoIP phone streamer, managed switch, printer, mobile device, PC, Velop, roku sticks & pihole


  1. are 91k approx requests in a 24 period excessive (considering I've configured my router to use pihole for DNS)?

NOTE: at one point, pihole rated limited my router.

NOTE1: sorry if above is a dumb question. It feels excessive but i can't compare to my previous setup and ISP because i didn't have all the existing devices currently in use

  1. are there more visual ways to review a client's domain requests?
  • Maybe in a graph, filtering on a single IP/client then grouping by domain requests?
  • Or a top 10 domains per client
  • or grouping by day, to see if for example, it was a commissioning of devices surge and then calmed down



No. Query volume is dependent on the clients, the software on the clients and your web habits.

1 Like


Is there a way to consolidate the data down though? So i can attempt to establish patterns or sources?

Or can i export to a spreadsheet e.g. dump to csv or something/

You can export all data from the long term database (/etc/pihole/pihole-FTL.db) by SQL.

1 Like

@jfb @yubiuser

I should have mentioned the excessive requests are arpa PTR.

I've seen a few posts (some quite old) talking about large volumes of PTR calls and pihole.

I'm not sure what to do about them.

I've got an IT background but i'm not strong on DNS.

I know a PTR is a reverse DNS lookup but I've never had volumes of requests like this on my pihole.

I did do a search on PTRs with pihole and turned conditional forwarding ON and i think it's reduced some of the calls.

Pihole has still processed nearly 68k requests from my router.

I checked the IPs - i can't make sense of the ones which are most prolifically requested:



Conditional Forwarding is irrelevant here:
Those are reverse lookups for public IP addresses.

Those addresses are owned and managed by Amazon, and reverse lookups for them seem to be censored (click for details)

OPT=15 is stating an RFC 8914 EDE error code, and a value of 16 translates to 4.17. Extended DNS Error Code 16 - Censored

~$ dig -x

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> -x @
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38430
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 16 ("..")
;     IN      PTR

;; Query time: 161 msec
;; WHEN: Thu Oct 21 08:17:09 CEST 2021
;; MSG SIZE  rcvd: 60

So Pi-hole is correctly forwarding those PTR requests upstream and returning the reply as received by its upstreams.

To stop those PTR requests, you'd have to single out the clients that issue those requests and then find a way to control that behaviour on those clients.

Since you claim that all those requests originate from your router, make sure you do not have port 53/DNS opened on your router - lest you would be running an open resolver.

@Bucking_Horn thanks for this

I too concluded all amazon (when i realised arpa IPs are in reverse).

I actually wondered if they were AWS servers.

Thanks for verifying this. I think it's the sheer volume AND the repetitive nature of the requests which are the issue (though i'd like to know who's phoning home). Perhaps because the reverse resolution is censored, so the requests persist.

I already have a suspicion as to which client is causing this and i didn't have these issues until i moved ISP (and got new equipment), so that shortlists the culprits (though of course it could conceivably be a new app, etc, though then i'd see it as as one of my computing device clients).

I don't "claim". I'm stating. Pihole is reporting my router as the requesting client. What i suspect is happening is a client is looking to the router for DNS resolution and router bounces request to pihole.

Thanks VERY much for the open resolver warning. I do understand (thankfully) what this means. However, my router is very locked down in some respects. There's not much i can interrogate or configure in the firewall. Having said that, i used an old skool (hopefully reputable; certainly established) firewall probe test (shields up from GRC - hope you approve) and my router passed with flying colours. All ports tested were null response.



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

hi all

Somewhere in-between a solution and a workround.

Basically, i don't know why but disabling the (linksys velop) router's DHCP server and using pihole for DHCP instead has stopped the excessive PTR requests i'd been experiencing.

In context, last 24 hours before changing over, router had sent:

  • 464461 requests to pihole

  • Top 10 domains were all from the router too (top 8 were ARPA, with number 1 being 71388 hits)

NOTE: Pihole was regularly having to rate limit my router requests too, such was the influx of requests.

Post pihole providing DHCP, next 24 hours saw this drop to:

  • 9470 (from router)

  • Top 5 domains were from router (top 4 were ARPA, with number 1 being 1292 hits)

NOTE: I've seen no further rate limiting.

I'm very pleased with the changes. I don't like abnormal IT behaviour and things appear 'normal' now.

Interestingly, the ARPA calls haven't ceased and have been to a different range of IPs than mentioned earlier in the thread (108.x.x.x but still amazon cloudfront) but their volumes are similar to other requests.

Obviously, i'd like to know what/why i'm getting requests from my router for name censored amazon cloudfront IPs but that's a different matter.

There's something dynamic occurring too, since the IPs being queried have changed (they were 18.x.x.x and are now 108.x.x.x)

Hope this info helps anyone else in a similar position to me.