1

I'm hosting several applications from home. My current "dirty" solution is, to forward multiple ports in my router. Downside is, I have to remember which ports serve which application. Plus, there are services/applications that need an nginx in the front to provide TLS secured connections, i.e. nextcloud.

I'd like to clean things up. The ideal solution would be to get a letsencrypt wildcard certificate and in nginx have something like (shortened pseudo config):

server {
    server_name nextcloud.mydyndnsdomain.org;
    location / {
        proxy_pass https://internalip:port;
    }
}
server {
    server_name someotherapplication.mydyndnsdomain.org;
    location / {
        proxy_pass https://internalip:anotherport;
    }
}

Problem is, I can't find a dyndns provider that allows subdomains. Multiple hostnames are allowed, but not subdomains to that.

Another solution I thought about would be something like this:

server {
    server_name mydyndnsdomain.org;
    location /nextcloud/ {
        proxy_pass https://internalip:port;
    }
    location /someotherapplication/ {
        proxy_pass https://internalip:anotherport;
    }
}

Problem is, that once I'm working with for example nextcloud further links are not working anymore, as the /nextcloud/ is missing in the URL. Therefore the "more correct" version of this would be

server {
    server_name mydyndnsdomain.org;
    location /nextcloud/ {
        redirect 301 https://internalip:port;
    }
    location /someotherapplication/ {
        redirect 301 https://internalip:anotherport;
    }
}

Problem is, that I don't benefit from a secured TLS connection anymore and I still have to port forward in the router and so on and so on.

Or of course I register multiple hostnames at my dyndns provider. But then I would again need multiple certificates and am limited to a certain number of hostnames. And have to remember which application is served under which hostname.

So my question is, how do other people do this? What is the recommended solution? Or is there something I misunderstood with my poor nginx skills?

1 Answer 1

1

All 3 methods can be made to work fairly easily.

Problem is, I can't find a dyndns provider that allows subdomains. Multiple hostnames are allowed, but not subdomains to that.

Purchase your own domain, then you'll be able to create as many subdomains under it as you want. There are two ways you can make it update the addresses dynamically:

Do it yourself: Purchase your own domain, host its nameservers at a DNS provider which has some form of API, make sure the DNS A records have a sufficiently low TTL configured on them (e.g. 5–10 minutes) and that's it – you have your own "dyndns" with unlimited subdomains.

The Certbot/LetsEncrypt community might be a good source of compatible (i.e. automatable) DNS providers, as DNS-based challenges are a requirement for obtaining a wildcard certificate from LetsEncrypt, so you'd need this functionality anyway. (Not that you need a wildcard certificate, really...)

There is very little difference between Certbot updating TXT records for LE challenges and a dyndns client updating A records, and some DNS providers even have an API compatible with dyndns updaters.


¹ The nameserver host doesn't have to be the same place as the registrar which sold you the domain – all registrars let you change the nameserver addresses, so you can e.g. buy a domain at Namecheap but host DNS at Linode or Route53 or whatever else is most convenient.

² The only thing that remains is the internal propagation delay between the DNS provider's nameservers – while most providers start serving the new records as soon as you submit them, there still are some which only reload their databases every 10-15 minutes, so beware of those if you need extremely quick updates.


Use current provider: Purchase your own domain, use CNAME records to point its various subdomains towards your existing dyndns name. This does not require any extra setup, neither from the Dyndns provider's side (they cannot distinguish a resolver following a CNAME from one just making a direct query), nor from your side (the usage of CNAME is invisible to both HTTP and TLS). Any regular nameserver will do, too, because the CNAME records themselves do not need updating.

When the CNAME is in place, when you visit e.g. https://cloud.example.com you'll automatically get the IP address of example.dyndns.org, but Nginx will still see you as trying to visit cloud.example.com and will choose the correct server{} block and certificate.

There are two downsides to this option: You're now managing the domain's configuration across two services, and you are still limited to IP address updates only – you most likely cannot use this for LE DNS challenges, so no wildcard certificate for you.

once I'm working with for example nextcloud further links are not working anymore, as the /nextcloud/ is missing in the URL.

Most webapps can be configured to expect themselves at any base URL you want. For example, Nextcloud has the overwritewebroot option for that.

Therefore the "more correct" version of this would be

redirect 301 https://internalip:port;

No, if you need the apps to be accessible from outside, that really should be your external address (and port) – the whole point of redirects is that they're handled by the client, and external clients won't be able to connect to your internal IP address.

Problem is, that I don't benefit from a secured TLS connection anymore

If your redirects point to different ports of the same dyndns domain, then there's nothing stopping you from serving TLS on all of those multiple ports of the same domain, even using the same certificate.

If some webapps need a frontend for TLS, then just configure the same Nginx with more server{} blocks which listen on different ports. For example, on port 443 you can serve redirects, and on port 8443 you can proxy / to Nextcloud.

1
  • Awesome answer, thank you.
    – fancyPants
    Jan 20, 2021 at 11:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .