I currently installed my piHole 4.4, (currently) one device is flooding the pi with *in-addr.arpa requests.
In 2 hours around 25k !!!
This is crazy, I think my raspberry will die soon.
The device has xubuntu 18.04 installed, what could cause this? I already deactivated avahi-daemon, but it is something else.
That can't be normal?
Found this:
/etc/pihole/pihole-FTL.conf: ANALYZE_ONLY_A_AND_AAAA=true
Changing the config can not be the correct solution?
I would suggest turning off Conditional Forwarding but without the debug token we asked for I'm unable to tell if that is enabled on your setup.
Why not?
Sorry, how does this work?
The log would be uploaded by the pi automatically and I can not review it before upload?
CONDITIONAL_FORWARDING=false
I am new to this.
But I want to know why are so many requests from ONE device and what could cause this.
With the option ANALYZE_ONLY_A_AND_AAAA=true it is less filtered?
I setup my router (fritzbox) :
Could this cause a problem?
Without the 1. Option, the Guest Network is not piHoled and with the 2. local DNS, I can additionally see separated statistics for each device.
The log List exploded from 40k to 80k. I added the ANALYZE_ONLY_A_AND_AAAA to the config, I cloud barely navigate.
However, I want to know urgently, why are there so many requests?
What is causing these on the device?
I hope someone can explain this behavior.
You probably have a routing loop somewhere, router pointed to Pi-hole and Pi-hole upstream to the router. But that's just a guess since I have no information to look at to give help.
Can I send you a pm with the log? The upload failed.
The debug log is sufficient?
The Requests are still at pihole.log, the deactivation in the config is not a solution.
When you generate a debug log, you have the option of whether to upload it the server or not. If you do choose to upload it to the server, you will be given an alphanumeric token. That is what we need to find your debug log on the server. The debug logs expire in 48 hours and only a handful of people on the Pi-hole team can access them (for your privacy).
A PTR request is when a device asks for the name of the client located at a specific IP. Without seeing the specifics of your in-addr.arpa queries, we can't tell you much more than that.
Please post the output from the following commands from the Pi terminal, which will help us understand the query activity.
echo ">top-clients >quit" | nc localhost 4711
echo ">top-domains >quit" | nc localhost 4711
grep arpa /var/log/pihole.log | tail -n25
Thanks.
Here is the output from the terminal: https://pastebin.com/edWchgzT
@jfb
btw. happy 2nd year anniversary @discourse.pi-hole.net 
What device is at IP 58? Is there any DNS or other similar software running on that device?
That client is doing reverse lookups on your network for clients on your LAN (IP 1, 35, 44, etc), plus lookups for remote lcients
What I don't see in the printout is any replies for these queries. Take a look through /var/log/pihole.log and see if there are replies for any of those queries.
On 58 is an xubuntu 18.04, there is nothing else, nothing special.
The device I use now, just firefox and thunderbird in use.
I thought it could be some ubuntu standard service ? 
So I deactivated avahi-daemon (first post), but the requests remain.
I can not find a reply in the log, can I check what is causing the reverse lookups on the xubuntu?
The problem is with that client. Pi-hole is behaving exactly as designed. For assistance on xubuntu, please visit a forum that covers that kind of help.
ok, this needs some more investigation.
Anyway, there are a lot requests for example an active ssh connection, every few seconds.
The ANALYZE_ONLY_A_AND_AAAA=true deactivated it in the statistics, but not in the log.
Can PTR excluded there too?
Shouldn't this continuous writing use up the SD card quickly?
Writing the logs in the ram (or something else) would be a better solution on long time?
At this point the SD card and logs are not where your attention should be. If you have an unknown SSH session from a box that is behaving badly then you have other problems going on.
I did now say anything from an unknown ssh session, it is the ssh session to the pihole.
Okay, great. Something is asking for a lot of PTRs. Sometimes that happens with things like seedboxes or torrent kind of applications. Something that is getting a lot of external connections and trying to find out what the FQDN is to log or display.
I'm not following you here. The client at 58 is connected to Pi-hole via SSH and sending PTR queries in this way? What is the relationship between any ssh sessions and the Pi-hole PTR queries?
I am not sure, but it seems to be firefox which I would never have suspected. It is almost any time open and even after opening a clean profile without addons ... rise these requests.
If firefox is closed and and ssh connection to the pi is active, there are only every few seconds PTR querys from 58 to the pi. I thought because of the ssh connection.
Thank for the help @ all 
What could I find out is, every single connection seems to end up with a lot of queries. For some reason, an example this forum website (ip), opened in firefox:
--
May 9 12:19:16 dnsmasq[6227]: query[PTR] 226.95.203.159.in-addr.arpa from 192.168.x.x
May 9 12:19:16 dnsmasq[6227]: cached 159.203.95.226 is NODATA-IPv4
May 9 12:19:17 dnsmasq[6227]: query[PTR] 226.95.203.159.in-addr.arpa from 192.168.x.x
May 9 12:19:17 dnsmasq[6227]: cached 159.203.95.226 is NODATA-IPv4
--
May 9 12:19:18 dnsmasq[6227]: query[PTR] 226.95.203.159.in-addr.arpa from 192.168.x.x
May 9 12:19:18 dnsmasq[6227]: cached 159.203.95.226 is NODATA-IPv4
May 9 12:19:19 dnsmasq[6227]: query[PTR] 226.95.203.159.in-addr.arpa from 192.168.x.x
May 9 12:19:19 dnsmasq[6227]: cached 159.203.95.226 is NODATA-IPv4
--
...
... and so on.
The response is NODATA-IPv4, maybe this is not correct?
The response is correct, since this IP (edit) is not found on the internet and cannot be resolved to a domain name:
dig -x 159.203.95.226
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> -x 159.203.95.226
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14221
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;226.95.203.159.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
95.203.159.in-addr.arpa. 3600 IN SOA ns1.digitalocean.com. hostmaster.95.203.159.in-addr.arpa. 1588703067 10800 3600 604800 1800
;; Query time: 967 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 09 12:19:25 CDT 2020
;; MSG SIZE rcvd: 123