“.home.arpa” for A records.

I run my own CA and DNS, and can create vanity TLDs like: a.git, a.webmail, b.sync, etc for internal services. These are CNAMEs pointing to A records.

do not use .local, as tempting as it may be

use .home personally

RFC 6762 defines the TLDs you can use safely in a local-only context:

*.intranet
*.internal
*.private
*.corp
*.home
*.lan

Be a selfhosting rebel, but stick to the RFCs!

I use .test a lot in my sandbox environments

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

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

Everything at my house has a TLD named after the road I live on (a founding father last name). Everything at my offsite at my dads house uses TLD named after the road he lives on (a woman’s first name).

It’s both arbitrary and practical. A number systems exist at both such as proxmox. truenas. pihole. plex. So it’s a good way to tell them appart without having to differentiate them in the domain name.

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

I just use my public domain (eg domain.com) and have split DNS setup.

I use home.arpa as the base dns as that play very well and are the official standard, then I have a domain for my reverse proxy. Of course I can use that domain for the whole network, but I like to split it up

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.