Domains for private networks

Networks
1

I’m planning to set up some some local+VPN services with TLS and a custom CA. The idea is that I want to pick something like mycoolservice.internal while being confident that .internal will never become a “real” TLD.

The most practical problem is that if .internal became a TLD that you could register then you will likely have trouble resolving “real” .internal sites. The more paranoid problem is that if you’ve roamed onto another network, someone might be able to present a valid certificate for mycoolservice.internal that isn’t yours, thereby grabbing data from your client.

From my research so far the most interesting candidate is relatively recent concept, RFC 8375 which reserves .home.arpa. as a domain you can use for this purpose. This has reached “proposed standard” stage, which is fairly promising.

Meanwhile RFC 6762 mentions a range of possibilities including .intranet, .internal, .private, etc., while simultaneously recommending you don’t do this at all.

The “safest” solution appears to be to use a domain you’ve registered yourself, ideally one not used for any public services to eliminate the possibility of things like cookie leakage. I don’t really want to go to that extra expense.

What’s everyone else done?

2

For these kinds of situations I’ve used cheap public domains. check out namecheap.com they have less desirable domains like fgfh.xyz for ~$3 a year.

That kind of domain with a lets encrypt certificate + certbot and you’ll be all done

1 Like
3

I’m going to be setting up a similar VPN situation soon and have gone with a subdomain of a domain we already own.
A lot of networks seem to use ‘.local’, ‘.modem’, and ‘.home’ already, depending on the CPE vendors whims.

1 Like
4

You’ve sold me, getting LE certs easily will be worth the expense. :+1:

5

yea i run off my own domain name too. Just opens all options and doesnt lock you out down the track.

I actually just expose everything to the internet with LE certs and make sure the auth is strong.

1 Like
6

Like most others I have a vanity domain and just use a subdomain of that for my home/internal services. So if you are willing to spend a few dollars each year and use LetsEncrypt that is probably the easiest option.

Just note that all certificates issued by LetsEncrypt (or any reputable CA) are publicly available in certificate transparency logs which can be looked up using a service like crt.sh (ie. certificates issued for ttug.au), so if you are concerned about any information leakage related to internal services, using a personal CA might be a better option. Using wildcard certificates could help to mitigate things a little bit.

Using a personal CA might end up being more hassle that it is worth… particularly around ensuring that the CA certificate is (and/or can be) installed on all your devices. At least there seem to be a few options for self-hosting a CA/ACME setup, so certificate generation wouldn’t be much harder than generating LetsEncrypt certificates (once the ACME service is setup).

I don’t expose any home/internal services publicly and use WireGuard when I’m away from home and need to connect back in (it is also simple enough my partner can use it to upload her photos to NextCloud while on holidays). I have been meaning to check out Tailscale/Headscale though for some of the fancier features they offer.

2 Likes
7

There was a decision from ICANN some time ago that they wouldn’t in fact permit anyone to register .home, .corp or .mail (after holding on to the registration fees for a few years for the companies who wanted to exploit them)

https://www.theregister.com/2018/02/12/icann_corp_home_mail_gtlds/

I realise that ICANN policy is pretty flimsy compared to an RFC but :person_shrugging: its a start.

However, more intriguing was a suggestion in the comments of using the user-assigned sections of ISO 3166-1:

From this comment

Reserved Top Level DNS Names

For that matter there are the user assigned code elements of ISO 3166-1 alpha-2. OK they are country codes rather than ccTLDs but we can be pretty certain that they won’t get used as ccTLDs as it would cause too much confusion.

TL;DR version: the following two letter combinations can currently be used as non-conflicting TLDs and are highly unlikely to ever conflict in the future - AA, QM-QZ, XA-XZ, and ZZ(*).

(*) Long beards optional.

.qx, anyone? How about .xt for that old school feel?

1 Like
8

The more people use the (semi) reserved TLDs the harder it is to sell them off later so it feels like a reason to use them as widely as possible.

1 Like
9

It does, however the flipside is that if they ever do sell them off later (e.g. ICANN board changes, or someone comes along and offers eleventy billion $ for .corp, etc), you’ll be SOL.