Unable to claim server using DNS

Plex Media Server NAS & Devices
15

Here we go :slight_smile:

Plex and not claiming using domain names

This sounds like a confusing way to do things and very much like a bug but it’s quite deliberate.

  1. IPv4 is broken into 3 classes:
    a. Class A - 1.x.x.x → 126.x.x.x
    b. Class B - 128.0.0.0 → 191.x.x.x
    c. Class C - 192.x.x.x → 223.x.x.x
  • Class A space is used by the main internet itself, extremely large companies, and whole governments. It’s also a very convenient way of partitioning the world’s traffic.
  • Class B space is used by large companies. Class B space allows for 65535 directly addressible hosts from the open internet although few are ever open.
  • Class C space is used by smaller companies. Class C space allows for 254 directly addressible hosts.

We consumers don’t need that much addressibility. Most of us only need a single point of presence to/on the internet. How to allow us to have multiple computers, all sharing the same address became a problem. To solve this, NAT (Network Address Translation) was created. We can have multiple LAN IP addresses sharing a single public (WAN) IP without collision.

Putting it to use

  1. NAT (Network Address Translation) - A technology which allows multiple addresses in one space to share a single address in another address space. This is what allows us to have multiple devices in our homes while having bare minimal footprint on the limited IPv4 address space.

  2. RFC-1918 defines the blocks of the IANA inernet address space which will never be routed over the internet.

  3. ISPs apply RFC-1918 rules to our LAN side of the modem/router. Any RFC-1918 address defined on our LAN will never be routed to the Internet.

  4. DNS maps names to addresses.
    a. DNS works by starting at the local host
    b. If local host can map name to an address, it does so and uses it.
    c. If not, it passes the given name string up to the next higher DNS resolver.
    d. Process continues until resolved or “NXDOMAIN” (not found).

  5. Combine RFC-1918 + DNS =>
    a. Local LAN hostnames will never exist in the Internet tables
    b. Private space can have a ‘private domain’ (mDNS, etc) which is 100% isolated from everything else because nothing of the local LAN is ever going out to the Internet.

How Plex uses this:

  1. Plex.tv operates in the global Internet address space (everyone can see it and it can see everyone).

  2. Most of our servers are private in our homes but some are public. We need a uniform way of identifying all of them.

  3. Everything on the Internet needs to be encrypted.

  4. Some of the things in our home don’t support encryption very well.

  5. Combine 1 + 2 + 3 above and get — Plex.tv → Private DNS server for Plex. The 4th requirement here is handled below.

  6. Simplify software by converting all LAN IP addresses to names – universal format.
    a. Chuckpa.server.hosting.com:32400
    b. TVS1282.home.lan:32400
    c. Map both names into UNIQUE private domain for “ChuckPa”; creating 23f4-9975dead-beef0000.plex.direct
    d. Add Encryption certificate to that private domain. (Plex creates a certificate for every individual user)
    e. Entries are defined in plex.tv for:
    Chuckpa.9975dead-beef0000.plex.direct
    TVS1282.9975dead-beef0000.plex.direct
    e. All of Chuck’s machines now are secured and it doesn’t matter if on LAN or remote.
    f. Plex/web asks Plex.tv “What machines does Chuck have and where are they?”
    g. Plex.tv sends the list above.

Where the fun happens:

  1. Lookup the numeric address of the desired device / server

  2. How does that address map into RFC-1918.
    a. If the address is an RFC-1918 address, it’s guaranteed to be LOCAL.
    b. If the address is public (which is what you get from a FQDN ← security magic occurs right here), We treat as remote regardless of actual location. (assume hostile)

  3. From your computer to your NAS (both on the same RFC-1918 network).
    a. Already know it’s private and need not be super strict.
    b. Your home lan provides its own basis for security
    c. Setting up a new server succeeds without special effort because we trust RFC-1918 is in control.

  4. If the server is remote, we have no trust and therefore
    a. Can’t trust who’s trying to take control of an unsecured server. (setup)
    b. Who the owner is if network/equipment fault has broken the trust relationship between server and Plex.tv
    c. Therefore: SSH and log into the host’s username/password (the foundation of trust)
    b. Create a SSH tunnel to it for the sole purpose of operating the GUI to administer it as if it were local LAN

The result:

  1. When plex.tv and your PMS trust each other, you authenticating with Plex.tv joins that circle.
  2. You can now use or administer the server via local LAN or when remote via http://app.plex.tv
PMS on Public Network