I've been using .lan, referenced in rfc6762[1] as a good alternative to the multicast .local
> We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:
That doesn't contradict anything I said. Private networks can be huge, e.g. in big companies, and they can still use .internal. .internal serves quite a different purpose to that proposed for .self, so the top level comment I replied to doesn't make much sense.
As I understand it, if you want to use domains internally for your home ("home") network, there's some DNS support for "home.arpa"[0].
0 - https://www.rfc-editor.org/rfc/rfc8375.html
I've been using .lan, referenced in rfc6762[1] as a good alternative to the multicast .local
> We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose:
[1]: https://datatracker.ietf.org/doc/html/rfc6762That's no use for self-hosting unless all your users are on your private network.
Tailnet and Magic DNS make it easy to bring other people or devices to your network, including simple authentication mechanisms to know who is who
That doesn't contradict anything I said. Private networks can be huge, e.g. in big companies, and they can still use .internal. .internal serves quite a different purpose to that proposed for .self, so the top level comment I replied to doesn't make much sense.
A VPN is literally a… (Very) Private Network.
Virtual, not Very