Qobuz refusing to play

Roon Core Machine

Core: Nucleus
Client: Mac OS 10.14.6 Mojave, Mac Mini, 3.2GHz Core i7, 32GB RAM

Networking Gear & Setup Details

Wired, Ubiquiti Networks. OpenBSD firewall, connecting to the Internet via a VPN, as described here:
https://blog.majid.info/broadband-setup/

Connected Audio Devices

Questyle CMA400i over USB, but CoreAudio is not working (see my other ticket). Using the Mac system output instead

Number of Tracks in Library

12,881 tracks

Description of Issue

Whenever I try to play a Qobuz track, I get the error message “This track is not currently available from Qobuz.” followed by “Too many failures, Stopping playback”.

I realize my network setup is unusual, but I am able to play Qobuz just fine using the Qobuz app on my iPad.

1 Like

Just to make sure this is not caused by my VPN, I set up source routing so the Roon Nucleus connects to the Internet directly and not via VPN, the Qobuz problem still occurs.

Hmmm. Switching source routing off (so it still goes through my VPN) but changing the Nucleus’ DNS server in DHCP to 1.1.1.1 (Cloudflare’s DNS server, similar to Google’s 8.8.8.8 but less privacy-invasive) seems to have addressed the problem. There is some DNS dependency at work.

The only thing I can think of is my DNS server (unbound) validates DNSSEC and there may be invalid records that CloudFlare lets through that unbound doesn’t.

I don’t like Internet of Things devices exfiltrating data behind my back via DNS, and the Nucleus is particularly at risk because by the nature of streaming, it has to be on my main LAN, not on the highly restricted VLANs I leash IoT devices to. My normal settings are to block direct DNS access (e.g. to 1.1.1.1 or 8.8.8.8) to only trusted machines, although I don’t yet implement the blacklist of DNS over HTTP servers this guy (works on security at GitHub) does.

Even more interesting. I keep seeing messages like this in my DNS server log:

2021-09-05 19:45:08.182520500 [1630871108] unbound[30175:1] info: 10.0.4.24 push.roonlabs.com. A IN
2021-09-05 19:45:08.182520500 [1630871108] unbound[30175:1] info: resolving push.roonlabs.com. A IN
2021-09-05 19:45:08.185969500 [1630871108] unbound[30175:0] info: 10.0.4.24 push.roonlabs.com. AAAA IN
2021-09-05 19:45:08.185981500 [1630871108] unbound[30175:0] info: resolving push.roonlabs.com. AAAA IN
2021-09-05 19:45:08.186017500 [1630871108] unbound[30175:0] info: error sending query to auth server 2001:4860:4802:38::6c port 53
2021-09-05 19:45:08.198966500 [1630871108] unbound[30175:1] info: response for push.roonlabs.com. A IN
2021-09-05 19:45:08.198967500 [1630871108] unbound[30175:1] info: reply from <roonlabs.com.> 216.239.34.108#53
2021-09-05 19:45:08.198967500 [1630871108] unbound[30175:1] info: query response was CNAME
2021-09-05 19:45:08.198973500 [1630871108] unbound[30175:1] info: resolving push.roonlabs.com. A IN
2021-09-05 19:45:08.199064500 [1630871108] unbound[30175:1] info: error sending query to auth server 2001:4860:4802:38::6e port 53
--
2021-09-05 19:45:08.273028500 [1630871108] unbound[30175:3] info: 10.0.4.24 roonlabs.net. AAAA IN
2021-09-05 19:45:08.273029500 [1630871108] unbound[30175:3] info: resolving roonlabs.net. AAAA IN

I don’t have IPv6 connectivity, so I disabled IPv6 in my unbound config:

server:
        do-ip6: no
        prefer-ip6: no

and reverted my DHCP settings to use the internal DNS server again on the Nucleus, it now works (along with not crashing the Roon Mac client when using a CoreAudio zone).

The fix also fixed the crashes in the Roon Mac client when using a CoreAudio zone:

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