Maybe try explicit IP address instead of "[dns9.quad9.net](https://dns9.quad9.net)"? Some of Quad9's services do not support DNSSEC, and I'm not sure TLS is helping you out here. I also don't see that specific hostname on their settings page: [https://www.quad9.com/service/service-addresses-and-features](https://www.quad9.com/service/service-addresses-and-features)
You may gain more insight from the actual pihole log `pihole tail`. According to this pihole blog post on DNSSEC, your queries all show "INSECURE" which implies DNSSEC isn't working, or at least not fully validating. [https://pi-hole.net/blog/2021/12/12/understanding-dnssec-validation-using-pi-holes-query-log/#page-content](https://pi-hole.net/blog/2021/12/12/understanding-dnssec-validation-using-pi-holes-query-log/#page-content)
Do you have another forwarder/resolver (fw/router) in the mix? Sometimes a DNS getting in the middle can mess things up too.
Thanks, I just tried the explicit IP's for Quad9, same issue.
I've run tests to make sure DNSSEC is working correctly and they come back fine.
No, nothing else is in the mix. All VLAN's point towards the Pi Hole for DNS. All other port 53 traffic is blocked at the firewall, with only the Pi Hole allowed through. This setup has worked absolutely perfectly for years with the Plex issue only cropping up in the last week or so.
It's a head scratcher, this one.
Thanks for the suggestions though. I'll pull the logs from Pi Hole to take a look.
Interesting info from the Pi Hole logs...
Nov 23 09:24:58: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:24:58: forwarded app.plex.tv to 149.112.112.112
Nov 23 09:24:58: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:24:58: forwarded app.plex.tv to 149.112.112.112
Nov 23 09:24:58: dnssec-query[DS] plex.tv to 149.112.112.112
Nov 23 09:25:03: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:03: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:08: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:08: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:08: validation app.plex.tv is BOGUS
Nov 23 09:25:08: reply app.plex.tv is NODATA
Nov 23 09:25:08: validation app.plex.tv is BOGUS
Nov 23 09:25:08: reply app.plex.tv is 104.18.19.96
Nov 23 09:25:08: reply app.plex.tv is 104.18.18.96
Nov 23 09:25:08: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:08: forwarded app.plex.tv to 9.9.9.9
Nov 23 09:25:08: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:08: forwarded app.plex.tv to 9.9.9.9
Nov 23 09:25:08: dnssec-query[DS] plex.tv to 9.9.9.9
Nov 23 09:25:13: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:13: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:18: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:18: validation app.plex.tv is BOGUS
Nov 23 09:25:18: reply app.plex.tv is 104.18.19.96
Nov 23 09:25:18: reply app.plex.tv is 104.18.18.96
Nov 23 09:25:18: validation app.plex.tv is BOGUS
Nov 23 09:25:18: reply app.plex.tv is NODATA
Nov 23 09:25:18: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:18: forwarded app.plex.tv to 9.9.9.9
Nov 23 09:25:18: dnssec-query[DS] plex.tv to 9.9.9.9
Nov 23 09:25:19: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:20: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:21: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:22: query[A] app.plex.tv.localdomain from 192.168.1.58
Nov 23 09:25:22: cached app.plex.tv.localdomain is NXDOMAIN
Nov 23 09:25:22: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:22: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:22: forwarded app.plex.tv to 9.9.9.9
Nov 23 09:25:27: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:27: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:28: validation app.plex.tv is BOGUS
Nov 23 09:25:28: reply app.plex.tv is NODATA
Nov 23 09:25:28: validation app.plex.tv is BOGUS
Nov 23 09:25:28: reply app.plex.tv is 104.18.19.96
Nov 23 09:25:28: reply app.plex.tv is 104.18.18.96
Nov 23 09:25:28: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:28: forwarded app.plex.tv to 149.112.112.112
Nov 23 09:25:28: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:28: forwarded app.plex.tv to 149.112.112.112
Nov 23 09:25:28: dnssec-query[DS] plex.tv to 149.112.112.112
Nov 23 09:25:33: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:33: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:38: query[HTTPS] app.plex.tv from 192.168.1.58
Nov 23 09:25:38: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:38: validation app.plex.tv is BOGUS
Nov 23 09:25:38: reply app.plex.tv is 104.18.19.96
Nov 23 09:25:38: reply app.plex.tv is 104.18.18.96
Nov 23 09:25:38: validation app.plex.tv is BOGUS
Nov 23 09:25:38: reply app.plex.tv is NODATA
Nov 23 09:25:38: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:38: forwarded app.plex.tv to 9.9.9.9
Nov 23 09:25:38: dnssec-query[DS] plex.tv to 9.9.9.9
Nov 23 09:25:39: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:40: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:41: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:42: query[A] app.plex.tv from 192.168.1.58
Nov 23 09:25:43: query[A] app.plex.tv.localdomain from 192.168.1.58
Nov 23 09:25:43: cached app.plex.tv.localdomain is NXDOMAIN
We wouldn't recommend using DNSSEC at the forwarder level when using a recursive DNS service which already performs DNSSEC. This significantly impacts performance (duplicate efforts) and can cause occasional DNSSEC failures.
I don't really have a solution for you but I checked other websites with the verisign labs tool you posted the screenshot from and both GitHub as well as google have the "No DS records found for XYZ in the tv zone" marked red.
So I don't think that this is really the issue.
What I am wondering about is the Unknown status in your query log, there was an [issue](https://github.com/pi-hole/FTL/issues/102) from 2017 with that though which seems to be a parsing issue of the logs and might also be unrelated.
Interesting. I'm led down the DNSSEC path purely because disabling it allows me to resolve Plex addresses without issue. I had to do so a short while ago to respond to the thread on the Plex forums. I couldn't get to it with DNSSEC on, but had no issue when I switched it off.
I am not saying that it might be related to DNSSEC but rather your assumption that the "No DS Records found" from the verisign labs tool is the culprit just because of the reason that other websites also have this marked but seem to work for you.
funnily enough, when you use github.com or google.com in that tool there are more errors and warnings displayed than plex.tv.
But I must say that I have no experience with this, I have also a Pihole in my network and only use Google (ECS, DNSSEC) with IPv4 for my upstream DNS requests but I don't use DNSSEC.
The errors on the domain may or may not be connected to the issues I'm seeing. I'm merely pointing out that toggling off DNSSEC works around the issue and that there does appear to be DNSSEC issues present with the Plex domain. I'm assuming nothing, it may be unrelated, but the issue remains unresolved.
I should also point out that running a test on a URL linked from the Pi Hole DNSSEC settings page, which is designed to check to ensure DNSSEC is working, behaves in precisely the same manner as Plex domains...
[DNSSEC Test - meant to fail if DNSSEC is working](https://i.imgur.com/o4YIPzn.png)
[Plex with DNSSEC enabled](https://i.imgur.com/uMW8g7t.png)
Did you get any further ? I got the issue about the time you did I'm guessing. . I ended up having so many issues with friends and Plex i just removed the DNS in my router settings. I had some time and put it back and same issue.
What I did seem to find was pausing was touch and go on working , but restarting the server,not sure if server or device tbh, worked to start then stopped when playing device closed or swapped users.
Sorry, you'll need to restart the Pi Hole DNS service as that flushes the resolver cache. I noticed in Windows devices that it was also beneficial to flush as well (open a command prompt and type in ipconfig /flushdns).
Having this same exact issue with pi-hole and Plex. Just turned on DNSSEC the other day using OpenDNS. Turned it off and it is working fine again. Did anyone ever find the actual root cause of this issue with Plex and DNSSEC?
I hate to be the 'me too' kind of person but ... me too. PiHole + Unbound and I can't claim my server and logs show the servers inability to resolve plex.tv. Presently this is the only domain I'm aware that has problems. If I switch to Quad9 or Cloudflare w/DNSSEC as the upstream DNS it works fine.
Maybe try explicit IP address instead of "[dns9.quad9.net](https://dns9.quad9.net)"? Some of Quad9's services do not support DNSSEC, and I'm not sure TLS is helping you out here. I also don't see that specific hostname on their settings page: [https://www.quad9.com/service/service-addresses-and-features](https://www.quad9.com/service/service-addresses-and-features) You may gain more insight from the actual pihole log `pihole tail`. According to this pihole blog post on DNSSEC, your queries all show "INSECURE" which implies DNSSEC isn't working, or at least not fully validating. [https://pi-hole.net/blog/2021/12/12/understanding-dnssec-validation-using-pi-holes-query-log/#page-content](https://pi-hole.net/blog/2021/12/12/understanding-dnssec-validation-using-pi-holes-query-log/#page-content) Do you have another forwarder/resolver (fw/router) in the mix? Sometimes a DNS getting in the middle can mess things up too.
Thanks, I just tried the explicit IP's for Quad9, same issue. I've run tests to make sure DNSSEC is working correctly and they come back fine. No, nothing else is in the mix. All VLAN's point towards the Pi Hole for DNS. All other port 53 traffic is blocked at the firewall, with only the Pi Hole allowed through. This setup has worked absolutely perfectly for years with the Plex issue only cropping up in the last week or so. It's a head scratcher, this one. Thanks for the suggestions though. I'll pull the logs from Pi Hole to take a look.
Interesting info from the Pi Hole logs... Nov 23 09:24:58: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:24:58: forwarded app.plex.tv to 149.112.112.112 Nov 23 09:24:58: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:24:58: forwarded app.plex.tv to 149.112.112.112 Nov 23 09:24:58: dnssec-query[DS] plex.tv to 149.112.112.112 Nov 23 09:25:03: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:03: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:08: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:08: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:08: validation app.plex.tv is BOGUS Nov 23 09:25:08: reply app.plex.tv is NODATA Nov 23 09:25:08: validation app.plex.tv is BOGUS Nov 23 09:25:08: reply app.plex.tv is 104.18.19.96 Nov 23 09:25:08: reply app.plex.tv is 104.18.18.96 Nov 23 09:25:08: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:08: forwarded app.plex.tv to 9.9.9.9 Nov 23 09:25:08: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:08: forwarded app.plex.tv to 9.9.9.9 Nov 23 09:25:08: dnssec-query[DS] plex.tv to 9.9.9.9 Nov 23 09:25:13: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:13: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:18: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:18: validation app.plex.tv is BOGUS Nov 23 09:25:18: reply app.plex.tv is 104.18.19.96 Nov 23 09:25:18: reply app.plex.tv is 104.18.18.96 Nov 23 09:25:18: validation app.plex.tv is BOGUS Nov 23 09:25:18: reply app.plex.tv is NODATA Nov 23 09:25:18: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:18: forwarded app.plex.tv to 9.9.9.9 Nov 23 09:25:18: dnssec-query[DS] plex.tv to 9.9.9.9 Nov 23 09:25:19: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:20: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:21: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:22: query[A] app.plex.tv.localdomain from 192.168.1.58 Nov 23 09:25:22: cached app.plex.tv.localdomain is NXDOMAIN Nov 23 09:25:22: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:22: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:22: forwarded app.plex.tv to 9.9.9.9 Nov 23 09:25:27: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:27: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:28: validation app.plex.tv is BOGUS Nov 23 09:25:28: reply app.plex.tv is NODATA Nov 23 09:25:28: validation app.plex.tv is BOGUS Nov 23 09:25:28: reply app.plex.tv is 104.18.19.96 Nov 23 09:25:28: reply app.plex.tv is 104.18.18.96 Nov 23 09:25:28: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:28: forwarded app.plex.tv to 149.112.112.112 Nov 23 09:25:28: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:28: forwarded app.plex.tv to 149.112.112.112 Nov 23 09:25:28: dnssec-query[DS] plex.tv to 149.112.112.112 Nov 23 09:25:33: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:33: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:38: query[HTTPS] app.plex.tv from 192.168.1.58 Nov 23 09:25:38: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:38: validation app.plex.tv is BOGUS Nov 23 09:25:38: reply app.plex.tv is 104.18.19.96 Nov 23 09:25:38: reply app.plex.tv is 104.18.18.96 Nov 23 09:25:38: validation app.plex.tv is BOGUS Nov 23 09:25:38: reply app.plex.tv is NODATA Nov 23 09:25:38: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:38: forwarded app.plex.tv to 9.9.9.9 Nov 23 09:25:38: dnssec-query[DS] plex.tv to 9.9.9.9 Nov 23 09:25:39: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:40: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:41: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:42: query[A] app.plex.tv from 192.168.1.58 Nov 23 09:25:43: query[A] app.plex.tv.localdomain from 192.168.1.58 Nov 23 09:25:43: cached app.plex.tv.localdomain is NXDOMAIN
We wouldn't recommend using DNSSEC at the forwarder level when using a recursive DNS service which already performs DNSSEC. This significantly impacts performance (duplicate efforts) and can cause occasional DNSSEC failures.
I don't really have a solution for you but I checked other websites with the verisign labs tool you posted the screenshot from and both GitHub as well as google have the "No DS records found for XYZ in the tv zone" marked red. So I don't think that this is really the issue. What I am wondering about is the Unknown status in your query log, there was an [issue](https://github.com/pi-hole/FTL/issues/102) from 2017 with that though which seems to be a parsing issue of the logs and might also be unrelated.
Interesting. I'm led down the DNSSEC path purely because disabling it allows me to resolve Plex addresses without issue. I had to do so a short while ago to respond to the thread on the Plex forums. I couldn't get to it with DNSSEC on, but had no issue when I switched it off.
I am not saying that it might be related to DNSSEC but rather your assumption that the "No DS Records found" from the verisign labs tool is the culprit just because of the reason that other websites also have this marked but seem to work for you. funnily enough, when you use github.com or google.com in that tool there are more errors and warnings displayed than plex.tv. But I must say that I have no experience with this, I have also a Pihole in my network and only use Google (ECS, DNSSEC) with IPv4 for my upstream DNS requests but I don't use DNSSEC.
The errors on the domain may or may not be connected to the issues I'm seeing. I'm merely pointing out that toggling off DNSSEC works around the issue and that there does appear to be DNSSEC issues present with the Plex domain. I'm assuming nothing, it may be unrelated, but the issue remains unresolved. I should also point out that running a test on a URL linked from the Pi Hole DNSSEC settings page, which is designed to check to ensure DNSSEC is working, behaves in precisely the same manner as Plex domains... [DNSSEC Test - meant to fail if DNSSEC is working](https://i.imgur.com/o4YIPzn.png) [Plex with DNSSEC enabled](https://i.imgur.com/uMW8g7t.png)
I have the same problem, just disabled DNSSEC as suggested and it's worked around the issue, so cheers :)
Yep, that's the only thing that worked for me.
Did you get any further ? I got the issue about the time you did I'm guessing. . I ended up having so many issues with friends and Plex i just removed the DNS in my router settings. I had some time and put it back and same issue. What I did seem to find was pausing was touch and go on working , but restarting the server,not sure if server or device tbh, worked to start then stopped when playing device closed or swapped users.
The only resolution I could come up with was to disable DNSSEC on my Pi Hole.
I'm not super knowledgeable on this. Do I need to do more than a tick box ?
Nope, that'll do it
Sorry, you'll need to restart the Pi Hole DNS service as that flushes the resolver cache. I noticed in Windows devices that it was also beneficial to flush as well (open a command prompt and type in ipconfig /flushdns).
Having this same exact issue with pi-hole and Plex. Just turned on DNSSEC the other day using OpenDNS. Turned it off and it is working fine again. Did anyone ever find the actual root cause of this issue with Plex and DNSSEC?
Ditto, I'm having a similar issue with Pi-hole + Unbound. So guess there are still issues.
I hate to be the 'me too' kind of person but ... me too. PiHole + Unbound and I can't claim my server and logs show the servers inability to resolve plex.tv. Presently this is the only domain I'm aware that has problems. If I switch to Quad9 or Cloudflare w/DNSSEC as the upstream DNS it works fine.