Firstly, I’m no expert in this, so if this post is (technically speaking) rubbish, please delete it or let it drop like a stone.
There once was a challenge to find places that e/OS sends data to Google.
Well, recently I stuffed up some network settings, and my phone couldn’t see the wifi as being connected to the internet. But once I fixed the settings it didn’t recover from that situation as quickly as my laptop or other devices on the network, so I restarted it. Then I happened to look at the query log on my pi-hole.
I an no /e/ rep but this is the Firebase crashlytics presentation to app devs.
App devs may be inclined to use it for various reasons.
Your second link seems to be the “submission point”. It seems to be a Google API, application programming interface (the clue in the name). The primary access to read submitted reports is expected to be the app devs and associates. I guess any of this could possibly be accessed by others within Google, idk but probably not by intention.
Crashlytics is said to collect its info by use of trackers. In my case trackers from apps which declare to contain it are reported blocked by Advanced Privacy and TrackerControl.
If the main reader of the report is the app dev then he won’t even see the reports from tracker blocked devices so they cannot even guess the proportion of such users.
well I would rather say: step 1 is to discern whether the OS or any of your individually installed apps sends these requests and you cannot discern via only the logs of pihole - as pihole only knows devices (or IP-adresses if you will).
Don´t blame the (any) OS for what your installed apps do (or … the websites that you visit with your browser…)
Thanks for the responses, I think you’re right.. the source of the DNS queries is most likely to be from apps, and not the OS. I appreciate the explanations you guys gave.. really helps to understand where the queries came from!