A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Not sure if I completely understand but I think you want public service 1 accessible on subdomains s1.domain.com and internal service 2 on s2.domain.com?
Just point the A record for s2 to an internal ip address (or a tailscale ip). The only thing dns does is translate a (sub)domain to an ip address. So outside of your network s2.domain.com wouldn't resolve but inside your network it would.
That's what I did:
*.selfhosting.domain.tld that points to my router's IP address, which then redirects to an nginx+certbot reverse proxy*.local.domain.tld that points to my local IP with CaddyThe only challenging part was to configure Caddy to issue SSL certificates using the DNS challenge since *.local.domain.tld isn't exposed to the outside world.
Or just use one, and then run a local DNS resolver like pihole or AdGuard home and just make a record for the same host locally. The local DNS resolver will resolve the local request before it reaches the public DNS.
I prefer to use a local DNS for internal services just so there is less publically available information about my internal network. No need to let everyone know what address space I use or which vlan certain services are on. Also means you don't have to wait for public DNS servers to update.
subdomains would work, though ive never worked on it without a gui. Time to do some learning i guess :)
OK, I didn't read before answering, probably ignore my answer below but I'll leave it up incase someone learns something from it.
Everyone is suggesting cloud flare tunnels which can be easy to use but locks you into a proprietary service. If you want to self host everything, you can set it up yourself with a reverse proxy like traefik
You will end up with service.local.domain.com and service.domain.com for local only apps and internet facing apps, all using HTTPS.
If you are familiar with traefik, watch a tutorial on that first, then come back and watch the above video.
Before I write a book. What are you using internally and externally for dns?
Edit: misunderstood what OP wanted to do, leaving this here in case it's interesting to anyone.
Sounds like what you are tyring to do is called Split Horizon DNS.
Requests from outside your network should resolve server.domain.com to the public IP, but requests from inside your network should resolve it to the private IP.
If that's what it is then you register the public IP with your nameservers. You also run a DNS service internally which you point all your computers at (likely by putting it as the DNS server in your networks DHCP settings). That DNS server is set up to return the private ip addresses for all your servers, and to forward any other requests to some external DNS like 1.1.1.1
I'm not sure what your use case or for needing to use the internal IP address from inside the network, but it might be to avoid traffic exiting your network just to be sent back in? Or you me a that you want external requests to go to one server and internal to go to another server? I'm which case the set up above still works, but on just use the appropriate IP addresses in the appropriate places.
This can be done easily on pihole and Adguard using the DNS alias feature.
So I run windows AD and have windows dns inside and cloudflare outside. I also run NPM for the web prox in my DMZ.
On the inside DNS I point the A record for NPMProxy.domain.com to the IP of my npm server. I than setup service1.domain.com inside npm to forward requests to the web server setup for service1. I than setup the CNAME record for service1.domain.com to point to NPMProxy.domain.com. This should complete your inside.
Outside I set the A record on cloudflare for service1.domain.com to my public IP address which will route again to NPM. This will complete the outside connectivity.
Make sure your firewall rules are set and proper ports open and you should be golden.
Not sure I fully understand your question or goal but you might benefit from setting up NAT reflection for your public stuff so when you are inside your nat you can still access everything with your external domain name like you are on the Internet. I see some people referencing split DNS also and that goes along with nat reflection.
https://docs.netgate.com/pfsense/en/latest/nat/reflection.html
There is a link to how you set it all up using pfsense.
Edit: dupe
Something like this?
https://docs.linuxserver.io/general/swag
and add authentication to private services
For publicly accessible services, look into Cloudflare Tunnels. For private or restricted access services, add a Cloudflare Application to the Tunnel. The Tunnel provides a VPN connection without exposing ports on your router, and the Application provides authentication for access.
Cloudflare tunnel is the simple answer here. Yourdomain.com points to the public instance, private.yourdomain.com points to the private instance. All you need to do is install cloudflared on any always on machine on your network and point the URLs to the internal IPs of the machines hosting the services.
The other suggestions here are fine but Cloudflare is the easiest solution to what you want plus it's free and simple to setup and maintain.