Hi guys,
I’ve noticed over the past few days that I can’t connect to Plex directly via their dashboard website (Plex) and it also shows I’m connected indirectly which i believe is via a relay server which is slow. After some digging it seems as though Unbound is the culprit.
Looking at this post on reddit https://www.reddit.com/r/PleX/comments/8oadfw/pihole_and_direct_connect/, the solution is to place the line below in the pi-hole.conf file however that file doesn’t exist in /etc/unbound/unbound.conf.d/. There is a dietpi.conf however there isn’t anywhere obvious in that to drop this line. Any ideas where this can go to fix the Plex issue?
private-domain: plex.direct
Thanks,
Dan
That’s done the trick, thanks for pointing me in the right direction.
I can see from the other thread the OP never responded to your last question about confirming what was done.
For me I simply did the following…
nano /etc/unbound/unbound.conf.d/plex.conf
Then added…
private-domain: "plex.direct"
Then restarted all services using dietpi-services, no need to reboot.
Cheers.
Here it is explained (bottom section): https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
But I didn’t really understand how plex.direct can be affected by DNS rebinding, as it is a public domain but does not point your local Plex instance 
. However, as it is a common case, obviously, shall we add this by default via dietpi-software when Plex and Unbound are installed together?
well or keep it simple and add private-domain: “plex.direct” to our defaul config file? Does it harm? Even if not used?
It is a public domain, having it in the default config file prevents it from being resolved. Not sure whether that domain is used for any other reason, but if I where a user I would ask why this is blocked by default.
Not a big deal to have an extra file added + removed on those installs/uninstalls.
ok agreed, let’s put the check to both software installations and pull/create the respective config file if not existing.
how to confirm that system accept unbound plex.direct file. in my other computer on lan with nslookup command this thing showup
"
plex.direct
Server: nuc.local
Address: 192.168.1.90
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: plex.direct
Address: 82.94.168.7
"
"
hello.plex.direct
Server: nuc.local
Address: 192.168.1.90
DNS request timed out.
timeout was 2 seconds.
Name: hello.plex.direct
"
is 82.94.168.7 is correct or my unbound machine ip address need to show (192.168.1.90)? what is the optimize result in nslookup command i expected if system works correct.
Hi,
I don’t think it is working this way for the DNS request to return a local IP. This is the description for private-domain: value according unbound documentation https://nlnetlabs.nl/documentation/unbound/unbound.conf/
private-domain: <domain name>
Allow this domain, and all its subdomains to contain private ad-
dresses. Give multiple times to allow multiple domain names to
contain private addresses. Default is none.
For me it looks like it allows private address to be allowed only.
By default, Unbound, like most routers too, does not accept DNS responses from upstream providers to contain a private IP address of your local network. An upstream provider cannot or must not know any private IP valid in your network, of course. Many routers and Unbound drop such answers as a security measure, as it could be misused by an attacker, triggering connections from your system to other systems in your private network (while believing to connect to a public host) and gathering private data by this. This is called DNS rebinding protection.
I didn’t fully understand how these secure Plex connections from their web app to your private Plex instance work, but they seem to require exactly that: A DNS response for plex.direct containing the IP of your private Plex instance while it actually is a public domain. They try to explain this behaviour, but as it is blocked by default by most DNS resolvers, I tend to call it bad design, relying on a method that is mostly seen as vulnerability, even if their particular implement it is not an actual security issue.
The private-domain setting now disables the DNS rebinding protection for this particular domain, similar to how one usually can add a particular domain to routers rebinding protection whitelists.
