Plex media server 1.23.0.4438 unable to access server content (could not resolve host plex.tv)

Many thanks to ChuckPa and Ridley, Plex 1.23 branch is now working for me.

Ridley worked on my server to isolate the issue and then came up with a quick mitigation, which I believe has been pushed out.

I am currently running the latest 1.23 release and it’s working fine now.

Issue stemmed from my eero Secure subscription, which hijacks DNS requests and passes them to the “secure” DNS servers.

These servers are responding with SERVFAIL when there is an attempt to resolve a domain that doesn’t exist, instead of returning an NXDOMAIN.

Ridley has mitigated this incorrect resolution in the Plex code, even though this is really an eero Secure problem. Props!

I have also raised this with eero for an official response.

2 Likes

Can you provide some more info on what fixed the issue for you? I don’t see a new version out yet for the plex server. I am also using eero secure. I had a feeling eero may have had something to do with it but disabling the eero secure features did not have any affect when I tried yesterday.

They’re still working on the new build. There’s a comment here:

Request for participants - PMS 1.23.x DNS investigation - #14 by ChuckPa

To change this on the eero, completely disable Advanced Security and Block Ads and Content Filters, and remove all blocked sites for the whole eero system. If any of these features are active for any profiles, the eero will capture DNS traffic for all network hosts.

Yeah I unchecked Advanced Security and Block Ads yesterday. I just learned that I also had to manually uncheck all the settings within each content filter profile even though the profiles where not being used. After doing that a few minutes ago the issue went away.

@Volts

Is this where I make a “Terrible routers do terrible things” comment or should I just print it on a T-shirt ? :rofl:

1 Like

I’ll take a size Large shirt, please. :tshirt:

I really like eero’s WiFi mesh! It’s the most “just works” system I’ve used. I’ve given them to friends and family.

So I’ll assume these SERVFAIL responses are just a bug.

But I already had these DNS-hijacking features turned off. I’ve tried DNS-based filtering over and over throughout the years, and it always breaks too much stuff.

Servers on WiFi ?

:space_invader: :space_invader: :space_invader: :space_invader:

NOT cool.

SERVFAIL is a bug on their part. BAD one too.
DNS hijacking by the router is just as bad as Windows doing it :rofl:

They support Ethernet too! No wireless servers for me. I’ll save a can of dehydrated water for you, though.

The DNS hijacking is clever, at least. Compare it to the Pihole community which goes to great lengths to force all DNS traffic through Piholes. Otherwise you can’t filter (security, adblock) for devices with hardcoded DNS servers. And smart kids will just change their DNS servers to get around blocks.

But it’s all a losing game. Troubleshooting DNS problems is a chore. Making block/allowlist entries is a chore.

And DNS-over-HTTPS is imminent, and will make DNS completely opaque anyway.

imminent? :rofl:

Already using it.
Still need to do proper ad blocking on the host and not break stuff :stuck_out_tongue:

1 Like

I mean it’s Coming Soon to things like Smart TVs and Internet-of-Crap appliances.

The guys who want to be certain that your washing machine displays an ad, they’ll find a way.

Yeah, agreed.

I use the Plex Docker Container plexpass on an Unraid Server which was working fine till 1.22 since 1.23 I have the error described in this thread. I changed back to plex latest branch and it was working again perfectly until plex latest was updated to 1.23.

My dig on the unraid docker host returns

root@nas01:~# dig plex.tv AAAA

; <<>> DiG 9.16.9 <<>> plex.tv AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49399
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;plex.tv.                       IN      AAAA

;; Query time: 2448 msec
;; SERVER: 192.168.100.254#53(192.168.100.254)
;; WHEN: Thu May 27 21:08:29 CEST 2021
;; MSG SIZE  rcvd: 25

dig in the docker container itself returns command not found as always.

I already completely reinstalled the container just preserving the database.
My network consists of unifi switching equipment, I use Sophos XG Firewall as a"router". The DNS Servers in my network environment are an AdGuard Home Docker and the Sophos XG as a secondary DNS. plex.tv is explicitly whitelisted as trusted domain to prevent any adblocking. My internet provider usually uses IPv6 for “normal” home users, I specifically let that be changed to IPv4, so my whole network is based on IPv4. IPv6 support inside Plex is also explicitly deactivated.

In a docker container –

nslookup -type=aaaa plex.tv

should do the trick. ( I forget if nslookup is included )

I’ve just realised that my Sophos XG Firewall had IPv6 Cloudflare DNS Servers entered and that it was set to “Choose server based on incoming requests record type”.

After changing that setting to “Choose IPv4 DNS server over IPv6” my resolve issues in the plex docker vanished.

1 Like

Hi all,

As mentioned in my earlier replies, I already had the issue resolved (while still having both IPv4 and IPv6 configurations enabled), however a range of other issues popped up on which I decided to roll-back to the stable branch for now due to limited time availability.

My dig was already in the first reply below. I’m running PMS on a bare Arch Linux system (not in Docker or anything), without any of the firewall things as mentioned by others, which could possibly limit me (also not in router).

Just to add to this, I’m an eero Secure user, and get the following:

dig plex.tv AAAA

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> plex.tv AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29286
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;plex.tv.			IN	AAAA

;; Query time: 22 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri May 28 12:09:15 BST 2021
;; MSG SIZE  rcvd: 25

The latest release 1.23.2.4600 seems to have resolved the issue without any changes to my eero setup.

Just updated to stable branch 1.23.1.4602, so far so good, thanks all :slight_smile:

Also haven’t seen the other issues as mentioned below (yet).

Hi, FWIW, I recently had to do a reinstall of my home server, and I’m also experiencing the same issue here (logs full of errors not able to resolve plex.tv).

My situation is very similar to @Broekmanium – I’m on a bare Arch Linux install, no docker etc. With 1.23.* I wasn’t able to claim the newly created server, and only when I downgrade to 1.22.* do things start working again.

I don’t use any Eero equipment – I have a Google WiFi mesh setup. I’ll try the new 1.23.1.4602 and also run dig and report back here.

Same issue – spent countless hours trying to get plex to claim the docker server with no joy. Kept getting the ERROR - Error issuing curl_easy_perform(handle): 6 in the logs.

Downgrading to 1.22.3.4523-d0ce30438 works after seeing this thread.

FYI I am using pihole with OpenDNS and DNSSEC enabled.

; <<>> DiG 9.16.8-Ubuntu <<>> plex.tv AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17896
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;plex.tv.                       IN      AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Jun 13 14:59:56 UTC 2021
;; MSG SIZE  rcvd: 36

@ovel2clock

Which modem/router do you use?

Is it an EERO ?

Thanks for the reply – I use pfsense with Google Fiber. DNS is being handled by pihole via OpenDNS (which has DNSSEC)