core
core copied to clipboard
home-assistant
DNS Requests for 'o427061.ingest.sentry.io'
The problem
After installing 2022.11 there are more than 3500 DNS requests a day for 'o427061.ingest.sentry.io' What are the requests for, and how to disable them?
I enabled/disabled Telemetry data in settings, with no effect.
What version of Home Assistant Core has the issue?
2022.11.1
What was the last working version of Home Assistant Core?
2022.10.x
What type of installation are you running?
Home Assistant Supervised
Integration causing the issue
No response
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Hey there @dcramer, @frenck, mind taking a look at this issue as it has been labeled with an integration (sentry) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of sentry can trigger bot actions by commenting:
-
@home-assistant closeCloses the issue. -
@home-assistant rename Awesome new titleChange the title of the issue. -
@home-assistant reopenReopen the issue. -
@home-assistant unassign sentryRemoves the current integration label and assignees on the issue, add the integration domain after the command.
(message by CodeOwnersMention)
sentry documentation sentry source (message by IssueLinks)
![home-assistant[bot] avatar](https://avatars.githubusercontent.com/in/97978?v=4 "Published by a pub.dev verified publisher"){kind=small}
I am noticing periodically recurring the very same after the upgrade of HA Supervised to core-2022.11.1. Not using the sentry integration nor Node Red. Although those DNS requests are blocked by Pi-Hole HA seems to work without any problems.
Same here for me, i'll just link a thread on HA community here: https://community.home-assistant.io/t/dns-requests-to-sentry-io/484379
I can also confirm, HA pings the exact same address as mentioned on this thread 5x every minute resulting in a gross amount of DNS requests. Looking at the stats this started somewhere on the 3rd or 4th of November.
I'm not sure if I love finding out that my HA is connecting to some seemingly random service (whether it is good or bad) through my AdGuard logs.
HA uses Sentry for monitoring the application. I can't comment on exactly what those requests are, but it's likely you have something blocking Sentry's ingest domain (which is where things like error reports get sent). IIRC you opt-in to this at some point in HA setup.
HA uses Sentry for monitoring the application. I can't comment on exactly what those requests are, but it's likely you have something blocking Sentry's ingest domain (which is where things like error reports get sent). IIRC you opt-in to this at some point in HA setup.
For what it's worth, yes, I'm blocking the requests to Sentry but all the Analytics permissions in HA are also turned off so I would expect the requests to Sentry also respect these permissions.
IIRC you opt-in to this at some point in HA setup.
Nope, absolutely not! I am always reading carefully before giving any consent to what data I am allowing to be send to the Net.
All 4 analytics within Settings --> System --> Statistics are turned "OFF" ever since.
What makes me wonder is that no moderator at the official HA forum nor a dev jumped in here or at the forum to clarify on the latter. Thus I assume these callings are on purpose although in contrary with the vision and the mission of "home automation that puts local control and privacy first."
However, until these access attempts to 'o427061.ingest.sentry.io' stop I have blocked the name resolution to that domain and additionally firewalled any egress attempts to the ip-addresses in question.
the failed attempts are also being logged in the supervisor log and pretty much makes it unusable ...
Just a heads-up response, so you all know: This is an issue and not intentional. Of course, crash information helps, but we have no interest in forcing this on anyone.
We are looking into it. We do use Sentry in quite a few places (also on lower levels), and it should only trigger when opted-in. The question is: Which part of the ecosystem is doing this? While that is being figured out, please rest assured the data is anonymous and doesn't contain sensitive data, or feel free to block the domain otherwise.
../Frenck
I am getting the same in my AdGuard list of blocked domains, 25000+ queries from o427061.ingest.sentry.io, I have opted out from all of the Home Assistant data collection options under Settings > System > Analytics
Hi @Shaderz This is actually a known issue in Supervisor 2022.10.2 that has been corrected in the Beta Version of Supervisor... (2022.11.1 and later) , Supervisor 2022.11.2 has been released to the Stable group. See this (closed) issue for details: https://github.com/home-assistant/supervisor/issues/3973
@Calimerorulez Do you still have Analytics Turned ON in the Settings? If you Do but Your Ad Blocking DNS is Still Blocking a427061.ingest.sentry.io... you WILL still see the requests in your DNS Logs...
the Questions is Do you want to share analytics them... if so... Whitelist the above DNS Entry else Turn Off Analytics in HA Settings....
Also because of the Naming schemes I have seen people confuse Core release numbers with Supervisor releases and vice versa ... just saying....
@jweston2112
Sorry, my mistake... I've indeed got Analytics turned on. Thank you for pointing that out!
HASS 2022.11.5 with frontend 20221108.0 also sends data to sentry from the browser. Eg: https://o1313669.ingest.sentry.io/api/[INT]/envelope/?sentry_key=[LONG-UID]&sentry_version=7
And this data isn't anonymous it includes the host name of my hass system, client browser version and operating system information. It also includes the OUATH2 code from my current session! Please stop!!
Interesting @TuxInvader, o1313669 isn't the Home Assistant account identifier (ours is o427061); additionally, we don't send data to sentry using the browser, but using the Home Assistant Core backend in Python. So, it must be something else. Maybe you have browser extensions installed or custom cards that do that?
Please stop!!
For your specific case, this is not originating from the Home Assistant project.
Ooops. Sorry - it looks like this was indeed a browser extension. Thank you!
This needs to be fixed, the amounts of requests is insane.
This is fixed. Last entry on my system was 14th November. Did you deactivate all the analytics? also on the mobile app?
This is fixed. Last entry on my system was 14th November. Did you deactivate all the analytics? also on the mobile app?
It hasn't been fixed. Almost all the queries are from Home Assistant OS, depite all 4 toggles being off in Analytics.
Edit: Ah nevermind, I see that the entries stop 24th November.
as of today 2.23.2023 with 4 options turn off I still got o427061.ingest.sentry.io 2539 hit just 12h in my block list ..
Same here, seeing a lot of these queries... Home Assistant 2023.3.1 Supervisor 2023.01.1 Operating System 9.5 Frontend 20230302.0 - latest
It seems the issue with telemetry requests to o427061.ingest.sentry.io has resurfaced with latest update to 2023.3.3. Even with a clean installation. I have three instances with exactly the same problem. One is minutes old and has no HACS and no add-ons, only what was autodiscovered and autoconfigured.
Last 24 hours
Interesting - in late December, i switched from running on a RasPi to LXC container on Proxmox - right now, i'm on 2023.3.3 as well but don't see any DNS requests to sentry.io (that being said: if you've the possibility to blacklist it, do so - and if you're bothered by the "Top Blocked Domains" entry -> remove that with an entry of the domain in Settings -> API -> Top Lists in Pi-hole)
Interesting - in late December, i switched from running on a RasPi to LXC container on Proxmox - right now, i'm on 2023.3.3 as well but don't see any DNS requests to sentry.io
I am on KVM (HAOS), you are on LXC (container/core/supervised)
Yup, that's why i mentioned it (it's container, fwiw). So, question is what was/is in HAOS (i think that is what i had installed on the RasPi, not 100% certain) that apparently isn't inside container...