Network Security Alerts Using Roon

I have been experiencing a weird phenomenon since the last big Roon upgrade. When I do things in Roon, such as delete an album from Tidal or Qobuz, or add an album, or play an album, my network security software reports a denial-of-service attack on my internal router. This is concerning. Details follow:

  • Details on your Core machine: Small Green Computer Sonic Transporter i7 (Linux, 4 GB RAM, 2 TB SSD, Roon 1.8 Build 884, Roon Server DB size 1.3 GB, Roon Server Cache Size 1.2 GB, Capacity Used 1.29 TB)
  • Details on your Remote: Sonore UltraRendu (Linux, RoonReady 1.1.38)
  • Networking details: U use the router I received from my Telco as outward-facing only, and my wireless router connects to that via Ethernet and faces inward only.
  • Telco router: Motorola NVG 589
  • Internal (wireless) router: Netgear Orbi RB750, 1 satellite. The two wireless stations are connected to each other via Ethernet over coaxial cable.
  • Audio devices in use: CD player, Amp (Lyngdorf TDAI 2170). The Lyngdorf connects to the Sonore UltraRendu via USB, and to the CD player via SPDIF - this is because the Lyngdorf is completely in the digital domain, and sends a digital signal to drive the speakers.
  • Library details: I have around 6200 albums in my library, split evenly between owned (ripped or downloaded audio files) and Tidal or Qobuz links.

This all began when I started a Roon library gardening project. I am in the process of switching my links to Qobuz exclusively, because Qobuz files sound noticeably better on my stereo system. The switching process involves going into my Roon library, clicking on an album linked to Tidal, and checking the Versions tab. If a Qobuz version exists, I link to that and go back out to the top view in the Library. I then right-click on the Tidal version and select Remove From Library from the menu at the top of the screen. Sometimes I will link to 5-7 Qobuz albums and then select all of them in the Library view, and then do a batch Remove From Library.

Sometimes (but not always) I get a message from my network security software that reads:

NETGEAR Armor detected and blocked a Denial of Service attack on RB750 from 1.1.1.1.

I checked the address 1.1.1.1 - it is the website of Cloudflare, an internet software provider. I get this message when I unlink a single album from Tidal and link the album from Qobuz, and also when I do the batch process described above. Moreover, I have started to get messages from my NETGEAR security software when I play linked albums on Roon.

In both cases (unlinking/linking and playing a linked album) the actions I have initiated proceed to conclusion - I am just getting these messages that a denial of service attack was blocked. What is weird is that these reference my internal router, as if Cloudflare were built into software I am running.

Does Roon use Cloudflare? (I am in the process of inquiring of other software vendors I can identify on my home network - the number os reasonably finite). As I said at the outset, this only happens when I am using Roon, and never with other software usage.

Roon notoriously makes a lot of requests to dns servers. 1.1.1.1 (from cloudflare) is a dns server. So either you have it configured as a dns server in your router or on the device running Roon core.

It’s not necessarily an attack, it’s just that Roon makes insane amounts of requests. I haven’t seen a decent explanation from Roon why that is.

Thanks, I sort of suspected this. With more research after my post I found that Cloudflare is built into my security software, and I also suspected Roon exhibits the behavior you describe. But why should Roon behave like this? (Question is for Roon software designers).

Roon does not directly contact Cloudflare DNS–it uses the DNS server and caching configured on your system, like any app would. This is normal stuff for applications that talk to cloud services.

It sounds like your security software is throwing a false positive–I would pursue this with them. They definitely should not be treating packets from 1.1.1.1, one of the most popular DNS servers on earth, as a DoS attack, and definitely not in the numbers that Roon would be capable of triggering.

It must be ignoring the TTL then as I’ve never seen anything fire out DNS queries like Roon does.

I have about 35.000 dns requests to resolve my backup destination :sweat_smile:. That daily backup itself takes only a few minutes.

Sure, it’s a false positive. It’s not enough to be considered a dos attack. But it’s still a lot. In those few minutes the backup takes, the location of the backup destination isn’t going to change. Plus, if it did change, that would probably be an issue regardless of whether you detected that or not.

@brian Why is it doing 35.000 dns requests for a single backup that only takes a couple minutes?

No other application I use does this, so I can’t believe it is “normal stuff for applications that talk to cloud services” in the observed volume and intensity. There is something excessive going here, and it is caused by Roon and Roon alone, and is not the fault of my security software. I am not a computer professional, but the act of deleting a Tidal link - sometimes only deleting a single Tidal link - causes this false positive reaction by my security software. It makes me wonder what is really going on here - what is Roon doing behind the scenes? What information, exactly, is being gathered and transmitted? What is its value, if it’s so important as to cause this sort of situation? I am now suspicious and wary.

It’s not malicious or intent on capturing any of your data it’s just poor programming.

I’ve always been of the opinion that Roon is front end code focused and have little interest in making the network stack efficient and this is why it does horrible things with DNS etc.

90% of the customer base won’t notice (or care) what Roon is doing on or over their network so it can be accepted as a by-product of the application.

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