Self-Hosted Main

I have an io domain - mylastname.io

AD domain is home.mylastname.io

A place I put most apps running on my Kubernetes cluster is *.apps.mylastname.io

I own both `mydomain.com` and `mydomain.net`, and the `.net` is all my internal services (eg `homeassistant.mydomain.net`). The public `.com` domain I use exclusively for email and a static site.

I had some old employer with a similar segmentation so it just made sense to me ¯\_(ツ)_/¯

For those using a pihole for .internal.example.com, how do you deal with DNSSEC on example.com? Or do you just not?

.local is mDNS - and I'm using that, saves me so much hassle with split-horizon issues etc.

I also use global DNS for local servers (AAAA records on my own domain), again, this eliminates split-horizon issues. Life is too short to deal with the hassle of running your own DNS server.

I've got a .com for my internal only services with tls and a .pro for my external facing services. I could probably throw them all on one but because legacy (I didn't think things through) I have two

*.oob.mydomain.tld

A customer of mine chose for his own domains.. and it was his mistake that he wanted specific "cool top level domains" in his network for his factory, storage facility and vehicles on the road that connected with wifi at home.

He decided, and I realized immediately that this would be a bad idea (*cough* .. no I didn't.. but lets pretend I did), that he wanted something that looked like;

• company.fabriek (fabrication)
• company.waren (warehousing)
• company.vrachtwagen (trucks)

I think he adopted the idea because I had a singular setup at my office/shop where my synology, placed in a 8U rack in the back on the 4th flloor with a hostname.. just a hostname "I.am.on.the.forth.floor.in.the.back". Just a singular name.. I remember him laughing when he found the server where the hostname said it was.

So, the systems (electronic toolbag for in the trucks) installed in the trucks would only work a 100% if connected to the wifi at home base. All interfaces with any relation to the outside world had to be brought within the lan to be able to get to warehouse data, and the fabrication department (his pride and joy) just did what it always did.. it fabricated stuff. All choices were made motivated by the path of least resistance.

Yeah.. a lot of stuff didn't work as planned. Mainly connectivity things that did not work as expected, misconfiguration of DHCP servers, VPN clients and all other types of "employee owned" gear that were unable to resolve the funky domains.

I started to protest, and explain why what I did was funny, but what he was doing was foolish.. especially after I gave him a rough idea of what was neede to be done. I proposed a split dns solution with a real domain, even that would have been easier and less intrusive to work on or fix things in for sure.. but it looked "less cool" according to his lordship. Customer is king is a stupid concept, but if the customer claims to be King, his highness can pay for the time required to serve him.

So..

Pick a singular host, get a real domain and setup a split DNS environment (easiest and funnest imo).. but if you don't care (and why should you :)) pick something fun and cool that makes sense to use for you. All our suggestions are pure personal preference in the end :)

lastname. systems

I used to own lastname.cloud and foolishly let that expire. Its one of my biggest regrets.

I use >!.cunt!< for my local TLD. Stands for Can't Use New Technologies from IT Crowd.

It makes it comnical when I let friends onto my wifi.

Get a real domain. Then you can use external stuff tonight you want.

.lab

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 *.mydomain.dev cos I'm a dev... Got it for public access but ended up using locally as well because it's more convenient.

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.

It.cave :p

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 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.

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.

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.

Nothing. I have all devices using tailscale DNS and I refer to things in my network by their host name directly.

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.

I just use my domain inside my network which is a .net

I've never used DNS in my local network (because it's additional burden to support, so I tried to avoid it), but couple of month ago when I needed several internal web-sites on standard http port, I've just came up with "localdomain."

Yep, it's non-standard too, but probability of it's usage of gTLD is lowest among all other variants because of it's usage in Unix world and how non-pretty it is :)