.space is the only answer, have to buy that though
Self-Hosted Main
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.
For Example
- Service: Dropbox - Alternative: Nextcloud
- Service: Google Reader - Alternative: Tiny Tiny RSS
- Service: Blogger - Alternative: WordPress
We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.
Useful Lists
- Awesome-Selfhosted List of Software
- Awesome-Sysadmin List of Software
I have a registered domain and using it like this: service.machine.location.myregistereddomain.cz
You can use Let's Encrypt certs inside lan if you use a real purchased domain.
I read the answers and I am wondering if I should change what I do.
I use the exact same domains and sundomains internally and externally. I simply have a DNS internally that will answer requests with local IP.
So I don't have to address my machines with a different name when I am outside or inside.
Can someone explain to me what I missed ?
I do this too. I don't think it's bad. Sometimes you can have weird issues. Only time I remember weirdness is I had wildcard enabled on public DNS. So if a local DNS wasn't available it would always resolve to the public IP. Can be confusing.
Managed to buy a really sweet domain so using that for both mail and local domain
currently I have names for my machines in my /etc/hosts files across some of my machines
A better way is to set the DHCP server to resolve local too via DNS.
So in my case proxmox.mydomain.com and proxmox both resolve to a local IP...without any need to configure IPs manually anywhere.
On opnsense it's under Unbound >> Register DHCP Leases
Get a real domain. Then you can use external stuff tonight you want.
i made up a not real, non-standard TLD that i use lol (.null)
I have a self signed CA that all my devices trust. Getting a real domain and just using that, with LetsEncrypt, would not have required me to explicitly trust my own CA, but hey, my system works.
and i know i know, RFCs, but it works, and doesn't break anything.
I use *.mydomain.dev cos I'm a dev... Got it for public access but ended up using locally as well because it's more convenient.
In home decided to use .dot because for some reason chrome and chromium based do not automatically redirect it to https ,(at least for now) when you just type in the address in address bar, and do not redirect to search. So much more comfortable... why?.... ok, it maybe break access to all .dot sites but I never see something for me in that zone so so don't care
I just just use my public domain internally with a separate sub domain assigned to each device and each service. Pihole serves the local IPs for all of those instead of querying the public servers. Anything that's meant to be internal only, doesn't have a public DNS record and isn't directly accessible from WAN.
I then host openVPN to keep my mobile devices within my network and behind pihole, able to access my internal services. The public records/domain is just for services I share with others and so that I can reach my VPN.
I've always considered 'domain.tld' to refer to the network (my lan in this case) and 'subdomain.domain.tld' to refer to the specific service/device within that network. Whether or not you can actually resolve that name and reach its service/device, plus how you're actually routed there depends on where you're connecting from (LAN/WAN/VPN).
I use .test a lot in my sandbox environments
It depends.
- Do you want to have access from outside of your network or do you want to host several services to the public (in the future)? Then I would recommend buying your own public domain. It doesn’t need to be a TLD.
- Do you only want to use your services privately? Then use
home.arpa
as explained in the rfc 8375.
I would discourage you from using popular but misleading „local“ domains like .lan
, .local
, .home
etc.
That is because those domains might already be available in public. So when you use .lan
for example your dns-queries might be forwarded to the public never resolving your privately hosted services name. It could also „leak“ private network information like on what port you try to access a service and how that services name is.
Also you should highly evade .local
which was also my mistake. Some services like MulticastDNS i.e. apple bonjour service rely on this domain. If you would use it unknown problems might be frustrating you.
So if you host everything private, go for .home.arpa
.
It.cave :p
I use .home as my internal network DNS name. I tend to name my servers and network based off movie-AI stuff; i.e., VIKI, Jarvis, Skynet, Mother, etc.
I have registered domains as well, I am just waiting on my fiber to finally get installed before I start messing wtih DNS records and certs.
I just run (shall we add the word) “proper” split DNS with the same names for anything publicly exposed, internal. And not everything is publicly exposed. It’s just a standard registered TLD.
It’s interesting how few responses here mention this. Why memorize two or more names for the same box/service when DNS easily handles it?
DHCP clients set their own internal DNS names internally or are forced at the DHCP server. Static addresses via MAC as desired.
They also get handed all the usual SRV records and special record types to find services, like the time server and such.
Truly interesting that split DNS isn’t popular amongst the self hosting crowd.
Type the name of the “thing” after setting it up correctly and you’ll be handed an appropriate address to reach it, no matter which of my networks you’re on.
If you’re a dhcp client you’ll have the proper search domain handed right to you too, no need to even type the domain.tld at all. Just the hostname.
I use .home for the Windows domain/internal hosts and .online for my external domain as it was cheap, and the name I wanted was available.
To access self hosted stuff with working SSL certs,.I set up split DNS. On the internal DNS sever, I have a forward lookup zone for the .online domain with static A records for .online and all the subdomains pointing at the internal address of a caddy reverse proxy.
Not sure this is what you want but I have a .one domain setup with local IPs.
So if one server is on 192.168.1.8 I point the domain to that and by visiting https://myserver.whatever.one I get to that server.
I don't self host much of anything in everyday life, but when I'm working on a LAN related project I always use .local. Android now supports MDNS, so I use it pretty much everywhere.
home.(real domain name)
I can use LetsEncrypt via DNS-01 challenge, if I want to have anything accessible externally but be able to resolve to an internal IP internally then that's a piece of cake to do too as a result.
dot lan. I don't need let'sencrypt. I just ceeate my own CA, my own (wildcard) certificates, and install the CA into all my boxes that I want or need to have certificate verification succeeding.
Technically every machine is supposed to have a registered TLD, even on a local network. That said, I use .lan
I had problems with .local because it’s used for MDNS and too lazy to figure out how that works so now I just use lan but I also own a .com domain so I have started to use that more