so it is expected that Plex would detect this address as well
Issue:
Plex does not detect the public IPv4 address 11.22.33.44 anymore: either the status “Public: Unknown IP” in Remote Access settings, or it detects the NAT64 address 31.3.104.161
Speculating here, but it appears to be that the code in PMS that does public IP address detection is reliant on DNS somehow, is that correct?
@ChuckPa Yes, the host (PMS server) is dual stack, with both IPv6 and IPv4 on the (only) interface. DNS server set manually on the Plex server, I’ve also tried it with setting the same DNS64 server as the upstream resolver on the router, same behaviour. PMS on Windows, Linux and macOS.
I’ve rebooted the server, and now PMS detects the NAT64 server’s IPv4 address (31.3.104.161) as the public IP address instead of the native IPv4 address (11.22.33.44) that for example whatsmyip.org correctly detects.
Can you reproduce this issue?
Update 1: When I refresh the IP detection, I see only one DNS query going out: plex.tv so I presume that hostname is used in the address detection process (PMS connects to plex.tv, and plex.tv communicates the origination IPv4 address back to the server?)
Update 2: OK I feel I’m getting closer: when a DNS query for plex.tv returns both an A and an AAAA record, as happens with DNS64, PMS will always use IPv6 to connect to plex.tv, which (naturally) fails to detect the correct IPv4 address. Even when I force IPv6 to fail by setting the plex.tv AAAA record to ::1 (localhost), Plex will still not fall back to the A record and IPv4, but simply time out.
Update 3: Just tested this some more and indeed, when I block the AAAA record for plex.tv entirely so PMS only receives an A record, then it all works as expected. So I think you’ll have to write something to catch this scenario: in case PMS receives both A and AAAA records for plex.tv, connect over IPv4 first, and only on failure fall back to IPv6.
That’s how the address detection works. Plex uses DNS to look up the service, and makes a connection to it. The plex.tv service reports the address that connected to it.
It’s common (and typically recommended) to prioritize AAAA when both AAAA and A exist. But I don’t think that’s the core problem.
I think I’m confused about your setup and goals. If you have dual-stack LAN and WAN, why are you using a DNS64 service?
I think it’s behaving exactly how it’s configured.
plex.tv has no AAAA record; MyPlex doesn’t support AAAA/IPv6.
The DNS64 server you’re using sees plex.tv as an IPv4-only resource, and generates a holographic AAAA-NAT64-funnel response.
Connections via that generated address succeed, and PMS accurately reports that it’s a NATted connection.
Is this maybe something plex.tv can reconsider? Over 25% of the world is dualstack now, significantly more in some economies. India is 75%, the US is 47%. For most of these users the v4 is behind a carrier grade nat (CGN) & the ipv6 performance, especially connection speed, is probably better, simpler.
I think I’m confused about your setup and goals. If you have dual-stack LAN and WAN, why are you using a DNS64 service?
The goal is to move as much traffic on the local network to IPv6 so IPv4 can be disabled on most devices - it’s a lot easier to manage that way.
At this point Plex clearly still needs IPv4, but it should behave correctly in a dual stack environment, regardless whether a regular DNS server or a DNS64 server is used.
I think it’s behaving exactly how it’s configured.
plex.tv has no AAAA record; MyPlex doesn’t support AAAA/IPv6.
That’s the thing: if MyPlex doesn’t do IPv6, why does PMS follow the AAAA record for plex.tv instead of the A record (which it also receives)?
Thing is, in a world where DNS64 is used more and more, you cannot assume that plex.tv will never return an AAAA record. In this specific case, plex.tv is not a normal host where it doesn’t matter if PMS connects using IPv4 or IPv6, here it is deliberately used in PMS to detect an IPv4 address, which will never work when you follow an AAAA record.
So yes, in general the behaviour is correct that applications should use the AAAA record first, but in this specific case, PMS will have to catch it.
The problem is that the DNS server is lying!
That’s the whole idea of RFC6147, hundreds of millions of people use DNS64 Like it or not, it’s an internet standard and used extensively on today’s internet, so as an application you should expect to encounter it sooner or later.
Another subtlety is that you’re using a third-party NAT64 service. That’s adding the remote (double) NAT.
If I’m thinking about this correctly, if you were running DNS64 and NAT64 yourself, there wouldn’t be any problem. The correct public IPv4 address would be discovered.
I don’t think Plex “should” do anything here … except implement real support for IPv6.
Section 6.3.2 merely points out that this can happen, not that it shouldn’t be done
I don’t think Plex “should” do anything here
Well Plex specifically uses plex.tv for IPv4 address detection, so the code should ensure that it always connects to that domain over IPv4, not doing so is an exception that should be caught. Sure Plex could do nothing, but that simply maintains the situation that Plex breaks on networks with DNS64.
except implement real support for IPv6
Yes of course they should do that (it was already flagged almost a decade ago), but in the mean time, at least make sure that it functions correctly over IPv4 in all dual stack environments.
Not all of them! That’s why I say Plex shouldn’t make changes.
DNS64 and NAT64 can enable Plex to function on IPv6-only hosts. If Plex ignored AAAA responses or refused to make IPv6 connections, Plex would break entirely on IPv6-only hosts that rely on those technologies.
<Sarah McLachlan>
You’re lucky enough to have IPv4; think of the IPv6-only children!
</Sarah McLachlan>
It’s an interesting problem though. Just brainstorming:
Hosts file entry on the affected box
Don’t use DNS64 on dual-stack hosts
Operate a DNS64 service; don’t return synthesized responses to dual-stack hosts
(I assume you still want A->AAAA synthesis of plex.tv records for queries from your IPv6-only hosts?)
(You could still use the 3rd-party NAT64 service)
Operate your own DNS64 and NAT64 services, with appropriate hole-punching in the NAT64 service
Ask the DNS64 provider to exclude AAAA synthesis for plex.tv records
(They won’t be interested in this, I don’t think - it would break others who need it.)
Since I’m running local DNS, I’ve ended up with a 6th option:
blacklisted plex.tv (i.e. dropping both the A and AAAA record), created local DNS entry for plex.tv with only an A-record
This works. Of course running NAT64 on the router would be better, but it doesn’t have this option. In fact, I’m not aware of any ISP anywhere in the world that provides a router that can do NAT64, unfortunately - they all seem to expect us to run dual stack LANs ‘forever’ even if it’s not necessary anymore.
Plex should not ignore AAAA records in general (as you say, it would break things on IPv6-only networks), but it should perform this one specific action of “IPv4 address detection” only through the A-record. That this breaks on IPv6-only networks is as expected, since there is no IPv4 address to detect. I suspect it could be as simple as a simple addition of an AF_INET hint on the getaddrinfo()call.
At some point, plex.tv will get an AAAA record anyway, like all servers on the internet - Plex can’t stay IPv4-only forever. So this is an issue that needs to be fixed anyway sooner or later. As for IPv6 address detection, you wouldn’t use the same method as Plex uses now (connecting to plex.tv and checking the source IP) since it would only detect your temporary privacy address, not your stable address.
Pretty successful actually - I haven’t found anything that doesn’t work, except Plex. At this point, only the machine that runs Plex Media Server gets an IPv4 address from the DHCP server, everything else doesn’t.
That said, I’m not running anything old, like classic games or a 10-year-old smart TV or printer or something, everything is “current”.
My only real annoyance is that neither my router nor my ISP does NAT64 so I have to rely on 3rd party NAT64. But otherwise it’s surprising how few things break in 2021 if you drop IPv4 altogther. I guess the mobile carriers have been doing NAT64 for so long now that most of the bugs have been ironed out by now.
That’s how the address detection works. Plex uses DNS to look up the service, and makes a connection to it. The 
Like it or not, it’s an internet standard and used extensively on today’s internet, so as an application you should expect to encounter it sooner or later.
