Another user reported:
Yeah I unchecked
Advanced SecurityandBlock Adsyesterday. 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.
It’s DNS hijacking (the blocking feature)… and then reporting incorrectly.
It’s not because of IPv6.
I still argue this is an issue with the libcurl implementation as it didn’t happen on previous versions of Plex – or any other program I’m currently using.
It sounds similar to this issue reported to the libcurl mailing list:
https://curl.se/mail/tracker-2013-11/0008.html
libcurl isn’t even attempting to look up the A records if the AAAA records return SERVFAIL
In one of these threads @ChuckPa said that they’re working around the issue in Plex and hope to have an updated build (or test build) available soonish.
The next post on the libcurl list points out that it’s a c-ares resolver issue.
Curl: [curl:bugs] #1283 curl c-ares ipv6 search order incorrect
I do agree, it seems like a combination of issues. Amazing that DNS is still hard in 2021.
Plex is completely hosed for me at this point - can’t play content, can’t update content.
TimeMay 27, 2021 12:07:08.443
LevelWarning
Thread0x7f2d32556b38
Message[MediaProviderManager] HTTP error requesting GET https://plex.tv/media/providers?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (6, Couldn’t resolve host name) (Could not resolve host: plex.tv)
I have an eero network, running latest version (4.57.4) on synology. This started happening as soon as I updated my TV Shows to use the latest scanner. I can’t even play tv shows now (says that a required codec is missing).
Ugh.
Downgrade Plex to 1.22.3 and you should be back in business until there’s a fix in place for this.
We’re just waiting for the build with the mitigation for these EERO devices.
(they need to fix it but we mitigated it for now)
Just gonna throw this out there, that sending SERVFAIL isn’t exactly wrong these days.
Look at that code:
switch result {
case "No error condition":
return NOERROR with client expected answer
case "No record for the request type":
return NOERROR
case "The request domain does not exist":
return NXDOMAIN
case "Refuse to perform the specified operation for policy reasons":
return REFUSE
default("Server failure: unable to process this query due to a problem with the name server"):
return SERVFAIL
They need to handle it. That’s what a DNS provider / relay does.
The correct answer in Plex’s case , when using AAAA searches, is “NXDOMAIN” for IPv6.
Is there an ETA on that build?
Right, but the paragraph immediatley following that code block:
Although the context hasn’t changed much, protocol extensions such as DNSSEC have been added, which makes the RCODE run out of space to express the server’s internal status. To keep backward compatibility, DNS servers have to squeeze various statuses into existing ones. This behavior could confuse the client, especially with the “catch-all” SERVFAIL: something went wrong but what exactly?
Again the issue here is the AAAA query failing (and being prioritized) while the A succeeds.
Either way, looking forward to the update! 
No ETA yet.
Looks like there was a typo or something which didn’t verify out as it should.
(I’m being ‘church mouse’ with their discussion about it)
Are you referring to this specific version? PlexMediaServer-1.22.3.4523-d0ce30438-x86_64_DSM6.spk?
Yep! I downgraded to 1.22.3 and everything is back to normal. Downgrade and wait for the patched version of 1.23.x 
Did you downgrade using the Synology package manager? I ask because Synology PM will not allow me to downgrade through the GUI. Or perhaps you’re not running on a Synology NAS? Thanks for your guidance on this, appreciate your help.
Downgrading Synology is performed by:
It’s a valid response when there’s actually an error. And it might even make sense for a filtering system to return SERVFAIL if a query has been blocked for policy reasons.
But NXDOMAIN isn’t an error. It has meaning and conveys information. Turning every valid NXDOMAIN into a SERVFAIL isn’t right.
Thank you! Downgraded, working well now. Whew!
If running docker, mitigation for eero has been available for a few hours.
Eg: using plexpass image, it just downloaded 1.23.2.4600-f06057b33, which has the issue mitigated.
Public image has 1.23.1.4571-6119e8eed, which should also be mitigated.
So stop and start your containers to pull down the new images and see if your eero issue is resolved.
Can confirm that 1.23.2.4600-f06057b33 fixes the DNS resolution issues on eero Networks.
Thanks again to the team for the rapid turnaround! 
