It would have been nice if they came up with something shorter like .lan.
Oh, that’s LAN - I thought you’d put ian and I was trying to get the joke. Stupid sans-serif fonts.
Shit, let’s hope the ICANN cops don’t find me out then… I’ve been using it for years!
Sorry. I chose .local and I’m sticking to it.
I was using .local, but it ran into too many conflicts with an mDNS service I host and vice versa. I switched to .lan, but I’m certainly not going to switch to .internal unless another conflict surfaces.
I’ve also developed a host-monitoring solution that uses mDNS, so I’m not about to break my own software. 😅
Yeah, I don’t really have a use at home for mDNS. None that I can think of, anyway. Pretty sure I was using it before MDNS was a thing.
Accessing printers? Resolving hostnames of internal hosts? I can’t imagine having a lan without mDNS
It’s also second only to .com in terms of query volume in ICANN’s Magnitude statistics with 980 mil vs .internal’s 60 mil. Not sure if that makes it a de facto standard, but it’s close.
I’m using .home and have not had any issues. Would you mind sharing what problems you’ve come across so I know what to expect?
The main problem I have is waking up in the middle of the night worrying that ICANN pulled some more stupid corrupt bullshit that only makes networking worse and breaks my config.
Just look elsewhere in this thread: someone thinks that using .honk as a joke is safe. But what about .horse? .baby? .barefoot? .cool? (I stopped scrolling through the list at this point but you can see how arbitrary and idiotic things have become.)
I still haven’t heard a convincing argument to not use .local and I see no reason to stop.
Mainly conflicts with mDNS. However it’s shitty IMHO that the mDNS spec snarfed a domain already in widespread use, should have used .mDNS or similar.
I’ve also used .local but .local could imply a local neighborhood. The word itself is based on “location”. Maybe a campus could be .local but the smaller networks would be .internal
Or, maybe they want to not confuse it with link-local or unique local addresses. Though, maybe all .internal networks should be using local (private) addresses?
I’ve had issues with .local on my Android device. Straight up doesn’t work. I had to change to .lan
It should be reserved for sex toys.
Just saying.
I used to wonder why porn sites aren’t required to use ‘.cum’ instead of ‘.com’…
Browsers barf at non https now. What are we supposed to do about certificates?
If you mean properly signed certificates (as opposed to self-signed) you’ll need a domain name, and you’ll need your LAN DNS server to resolve a made-up subdomain like lan.domain.com. With that you can get a wildcard Let’s Encrypt certificate for *.lan.domain.com and all your https://whatever.lan.domain.com URLs will work normally in any browser (for as long as you’re on the LAN).
Right, main point of my comment is that .internal is harder to use that it immediately sounds. I don’t even know how to install a new CA root into Android Firefox. Maybe there is a way to do it, but it is pretty limited compared to the desktop version.
You can’t install a root CA in Firefox for android.
You have to install the cert in android and set Firefox to use the android truststore.
You have to go in Firefox settings>about Firefox and tap the Firefox logo for a few times. You then have a hidden menu where you can set Firefox to not use its internal trust store.
You then have to live with a permanent warning in androids quick setting that your traffic might be captured because of the root ca you installed.
It does work, but it sucks.
You do not have to install a root CA if you use let’s encrypt, their root certificate is trusted by any system and your requested wildcard Certificate is trusted via chain of trust
They didn’t make this too be easy to use. They don’t give a shit about that. That isn’t their job in the slightest.
They reserved a TLD, that’s all.
You can use any TLD you want on your internal network and DNS and you have always been able to do that. It would be stupid to use an already existing domain and TLD but you absolutely can. This just changes so that it’s not stupid to use .internal
Nothing, this is not about that.
This change gives you the guarantee that .internal domains will never be registered officially, so you can use them without the risk of your stuff breaking should ICANN ever decide to make whatever TLD you’re using an official TLD.
That scenario has happened in the past, for example for users of FR!TZBox routers which use fritz.box. .box became available for purchase and someone bought fritz.box, which broke browser UIs. This could’ve even been used maliciously, but thankfully it wasn’t.
How do you propose to get LetsEncrypt to offer you a certificate for a domain name you do not and cannot control?
@JackbyDev Why would that be a question at all? Buy a domain name and take care of your dns records.
that’s an odd way to say that you don’t own any domains. that’s step one, but does it even need to be said?
Quite literally my first thought. Great, but I can’t issue certs against that.
One of the major reasons I have a domain name is so that I can issue certs that just work against any and all devices. For resources on my network. Home or work, some thing.
To folks recommending a private CA, that’s a quick way to some serious frustration. For some arguably good reasons. On some devices I could easily add a CA to, others are annoying or downright bullshit, and yet others are pretty much impossible. Then that last set that’s the most persnickety, guests, where it’d be downright rude!
Being able to issue public certs is easily is great! I don’t use .local much because if it’s worth naming, it’s worth securing.
My Asus router is actually able to get a certificate and use DDNS which is really interesting.
You can set up your own CA, sign certs and distribute the root to every one of your devices if you really wanted to.
That sounds like a bad idea, you would need your CA and your root certs to be completely air gapped for it to be even remotely safe.
Why?
That’s a rather absolutist claim when you don’t know the orgs threat model.
What if I told you, businesses routinely do this to their own machines in order to make a deliberate MitM attack to log what their employees do?
In this case, it’d be a really targetted attack to break into their locally hosted server, to steal the CA key, and also install a forced VPN/reroute in order to service up MitM attacks or similar. And to what end? Maybe if you’re a billionaire, I’d suggest not doing this. Otherwise, I’d wonder why you’d (as in the average user) be the target of someone that would need to spend a lot of time and money doing the reconnaissance needed to break in to do anything bad.
As opposed to what, the domain certificate? Which can’t be air-gapped because it needs to be used by services and reverse proxies.
I found options like .local and now .internal way too long for my private stuff. So I managed to get a two-letter domain from some obscure TLD and with Cloudflare as DNS I can use Caddy to get Let’s Encrypt certs for hosts that resolve to 10.0.0.0/8 IPs. Caddy has plugins for other DNS providers, if you don’t want to go with Cloudflare.
Might be an idea to not use any public A records and just use it for cert issuance, and Stick with private resolvers for private use.
It’s a domain with hosts that all resolve to private IP addresses. I don’t care if someone manages to see hosts like vaultwarden, cloud, docs or photos through enumeration if they all resolve to 10.0.0.0/8 addresses. Setting up a private resolver and private PKI is just too much of a bother.
Maybe browsers could be configured to automatically accept the first certificate they see for a given .internal domain, and then raise a warning if it ever changes, probably with a special banner to teach the user what an .internal name means the first time they see one
Why do I care what ICANN says I can do on my own network? It’s my network, I do what I want.
Try using .com for your internal network and watch the problems arise. Their choice to reserve .internal helps people avoid fqdn collisions.
Well as long as the TLD isn’t used by anyone it should work internally regardless of what ICANN says, especially if I add it to etc/hosts
Sure, you can do whatever you want. You could even use non-rfc1918 addresses and nobody can stop you. It’s just not always a great idea for your own network’s functionality and security. You can use an unregistered TLD if you want, but it’s worth knowing that when people and companies did that in the past, and the TLD was later registered, things didn’t turn out well for them. You wouldn’t expect .foo to be a TLD, right? And it wasn’t, until it was.
German router and network products company AVM learned the hard way that this is a bad idea. They use fritz.box for their router interface page and it was great until tld .box became publicly available and somebody registered fritz.box.
Having a reserved local/internal only tld is really great to prevent such issues.
Certain domain names are locally routed only. So if you use internal or local as a tld, you can just assign whatever names you want and your computer won’t go looking out on the internet for them. This means you and I can both have fileserver.local as an address on our respective network without conflicting. It’s the URI equivalent of 192.168.0.0/16.
Interesting that you should use “.local” as an example, as that one’s extra special, aka Multicast DNS
The value of the DNS is that we all use the same one. You can declare independence, but you’d lose out on that value.
