It was just always so annoying having to go into the iPhone keyboard punctuation twice for each domain
takeda@lemmy.world
on 08 Aug 2024 07:06
nextcollapse
I guess no one offered anything for .internal
solrize@lemmy.world
on 08 Aug 2024 07:12
nextcollapse
Browsers barf at non https now. What are we supposed to do about certificates?
exu@feditown.com
on 08 Aug 2024 07:14
nextcollapse
You can set up your own CA, sign certs and distribute the root to every one of your devices if you really wanted to.
solrize@lemmy.world
on 08 Aug 2024 07:19
nextcollapse
Yeah I know about that, I’ve done it. It’s just a PITA to do it even slightly carefully.
BestBouclettes@jlai.lu
on 08 Aug 2024 07:56
collapse
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.
vzq@lemmy.blahaj.zone
on 08 Aug 2024 08:35
nextcollapse
Why?
That’s a rather absolutist claim when you don’t know the orgs threat model.
BestBouclettes@jlai.lu
on 08 Aug 2024 08:57
collapse
For self hosting at least, having your own CA is a pain in the ass to make sure everything is safe and that nobody except you has access to your CA root key.
I’m not saying it’s not doable, but it’s definitely a lot of work and potentially a big security risk if you’re not 100% certain of what you’re doing.
Just use only VPN to access your services behind the reverse proxy, if you want prevent unauthorised connections.
CA certificates are not here to prevent someone accessing a site, they are here, so that you can be sure, that the server you are talking to is really the one belonging to the domain you entered and to establish a tunnel in order to send the API calls (html, css, javascript etc.) and answers encrypted.
BestBouclettes@jlai.lu
on 08 Aug 2024 09:58
collapse
That’s the problem, if anyone somehow gets your root CA key, your encryption is pretty much gone and they can sign whatever they want with your CA.
It’s a lot of work to make sure it’s safe in a home setup.
prime_number_314159@lemmy.world
on 08 Aug 2024 10:05
collapse
You can just issue new certificates one per year, and otherwise keep your personal root CA encrypted. If someone is into your system to the point they can get the key as you use it, there are bigger things to worry about than them impersonating your own services to you.
And additionally, you can sign intermediate Certificates reducing the risk even more, since you can revoke and re-issue new ones any time.
atzanteol@sh.itjust.works
on 08 Aug 2024 13:02
collapse
No worse than protecting your ssh key. Just keep it somewhere safe.
lemmyvore@feddit.nl
on 08 Aug 2024 08:56
nextcollapse
As opposed to what, the domain certificate? Which can’t be air-gapped because it needs to be used by services and reverse proxies.
BestBouclettes@jlai.lu
on 08 Aug 2024 09:51
collapse
The domain certificate is public and its key is private? That’s basically it, if anyone gets access to your key, they can sign with your name and generate certificates without your knowledge.
That’s my opinion and the main reason why I wouldn’t have a self hosted CA, maybe I’m wrong or misled, but it’s a lot of work to ensure everything is safe, only for a self hosted setup.
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.
BestBouclettes@jlai.lu
on 08 Aug 2024 09:55
nextcollapse
I’m talking about home hosting and private keys. Not businesses with people whose full time job is to make sure everything runs fine.
I’m a nobody and I regularly have people/bots testing my router. I’m not monitoring my whole setup yet and if someone gets in I would probably not notice until it’s too late.
So hosting my own CA is a hassle and a security risk I’m not willing to put work into.
Findmysec@infosec.pub
on 08 Aug 2024 12:20
collapse
Yeah that’s your situation. Some people are fine with it
Findmysec@infosec.pub
on 08 Aug 2024 12:19
collapse
Ah, you mean they put the cert in a transparent proxy which logs all traffic? Neat idea, I should try it at home
They (the service that provides both web protection and logging) installs their own root certificate. Then creates certs for sites on demand, and it will route web traffic through their own proxy, yes.
It's why I don't do anything personal at all on the work laptop. I know they have logs of everything everyone does.
egonallanon@lemm.ee
on 08 Aug 2024 07:17
nextcollapse
Either ignore like I do or add a self signed cert to trusted root and use that for your services. Will work fine unless you’re letting external folks access your self hosted stuff.
lemmyvore@feddit.nl
on 08 Aug 2024 08:54
nextcollapse
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 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
That’s if you have a regular domain instead of.internal unless I’m mixing something. Topic of thread is .internal as if it were something new. Using a regular domain and public CA has always been possible.
lemmyvore@feddit.nl
on 08 Aug 2024 09:52
nextcollapse
This is not a new problem, .internal is just a new gimmick but people have been using .lan and whatnot for ages.
Certificates are a web-specific problem but there’s more to intranets than HTTPS. All devices on my network get a .lan name but not all of them run a web app.
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
fine_sandy_bottom@lemmy.federate.cc
on 08 Aug 2024 21:55
collapse
No one is saying it is their job.
Merely that using a TLD like .internal requires some consideration regarding ssl certificates.
This is about an ICANN decision. TLS has nothing to do with that.
Also you don’t really need TLS for self hosting. You can if you want though.
fine_sandy_bottom@lemmy.federate.cc
on 09 Aug 2024 03:02
nextcollapse
Because people can discuss whatever they like?
If you don’t like it just down vote it.
JackbyDev@programming.dev
on 09 Aug 2024 04:11
collapse
People can talk about whatever they want whenever they want. The discussion naturally went to the challenges of getting non-self-signed certificates for this new TLD. That’s all.
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.
state_electrician@discuss.tchncs.de
on 08 Aug 2024 11:23
nextcollapse
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.
state_electrician@discuss.tchncs.de
on 08 Aug 2024 12:14
collapse
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.
fine_sandy_bottom@lemmy.federate.cc
on 08 Aug 2024 21:58
collapse
My set up is similar to this but I’m using wildcards.
So all my containers are on 10.0.0.0/8, and public dns server resolves *.sub.domain.com to 10.0.0.2, which is a reverse proxy for the containers.
Findmysec@infosec.pub
on 08 Aug 2024 12:14
nextcollapse
Private CA is the only way for domains which cannot be resolved on the Internet
JackbyDev@programming.dev
on 09 Aug 2024 04:09
collapse
How do you propose to get LetsEncrypt to offer you a certificate for a domain name you do not and cannot control?
winterschon@mastodon.bsd.cafe
on 09 Aug 2024 08:08
collapse
@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?
JackbyDev@programming.dev
on 09 Aug 2024 13:09
collapse
You cannot buy .internal domains. That’s my point.
possiblylinux127@lemmy.zip
on 08 Aug 2024 15:29
nextcollapse
Accept them
BlueBockser@programming.dev
on 08 Aug 2024 16:56
nextcollapse
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.
wolo@lemmy.blahaj.zone
on 08 Aug 2024 19:14
nextcollapse
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
ayyy@sh.itjust.works
on 09 Aug 2024 06:27
collapse
The main reason this will never happen is that the browser vendors make massive revenue and profit margins off of The Cloud and would really prefer that the core concept of a LAN just dies so you pay your rent to them.
rushaction@programming.dev
on 09 Aug 2024 00:20
collapse
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.
JackbyDev@programming.dev
on 09 Aug 2024 03:57
nextcollapse
My Asus router is actually able to get a certificate and use DDNS which is really interesting.
ayyy@sh.itjust.works
on 09 Aug 2024 06:24
collapse
Makes ya wonder what else it’s doing that for…
JackbyDev@programming.dev
on 09 Aug 2024 17:52
collapse
So you can access your router’s config page without blasting your password in plaintext or getting certificate warnings. It’s an optional feature.
Railing5132@lemmy.world
on 09 Aug 2024 10:48
collapse
Same thing we do with .local - “click here to proceed (unsafe)” :D
Set up my work’s network waay back on NT4. 0 as .local cuz I was learning and didn’t know any better, has been that way ever since.
AlexWIWA@lemmy.ml
on 08 Aug 2024 07:13
nextcollapse
Thank god. Now iOS will finally recognize it
Violet_McQuasional@feddit.uk
on 08 Aug 2024 07:45
nextcollapse
Interesting. I’ve been using “.home.arpa” for a while now, since that’s one of the other often used ways.
rikudou@lemmings.world
on 08 Aug 2024 08:43
nextcollapse
We use .lh, short for localhost. For local network services I use service discovery and .local. And for internal stuff we just use a subdomain of our domain.
dhtseany@lemmy.ml
on 08 Aug 2024 09:50
nextcollapse
I still haven’t heard a convincing argument to not use .local and I see no reason to stop.
SirEDCaLot@lemmy.today
on 08 Aug 2024 10:17
nextcollapse
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.
xcjs@programming.dev
on 08 Aug 2024 16:20
collapse
That I agree with. Microsoft drafted the recommendation to use it for local networks, and Apple ignored it or co-opted it for mDNS.
ShortFuse@lemmy.world
on 08 Aug 2024 12:41
nextcollapse
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?
KingThrillgore@lemmy.ml
on 08 Aug 2024 13:15
nextcollapse
You mean mDNS/Zeroconf are using a tld that was already being used.
corsicanguppy@lemmy.ca
on 08 Aug 2024 14:28
nextcollapse
Tell me you don’t share a net with Macs without using those words.
xcjs@programming.dev
on 08 Aug 2024 16:19
nextcollapse
Macs aren’t the only thing that use mDNS, either. I have a host monitoring solution that I wrote that uses it.
ChapulinColorado@lemmy.world
on 08 Aug 2024 19:18
nextcollapse
Even on windows sometimes depending on the target host, I’ve had to type host.local. (Final dot to do exact match) instead of host.local
This didn’t seem to affect other domains. I’m assuming it was due to special handling of .local
ayyy@sh.itjust.works
on 09 Aug 2024 05:43
collapse
mDNS hasn’t been a just-Apple thing for decades. Do you still call it Ren-dess-voos like the Gaston character in Beauty and the Beast?
billwashere@lemmy.world
on 19 Aug 2024 19:25
collapse
My main issue was it doesn’t play well with Macs.
justme@lemmy.dbzer0.com
on 08 Aug 2024 10:29
nextcollapse
I went with .home and so far the problems are within reason
anytimesoon@feddit.uk
on 08 Aug 2024 21:18
collapse
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?
ayyy@sh.itjust.works
on 09 Aug 2024 05:40
collapse
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.)
chrisbit@leminal.space
on 08 Aug 2024 10:38
nextcollapse
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.
EnderMB@lemmy.world
on 08 Aug 2024 13:34
nextcollapse
I switched from .local to .honk and I’m never looking back.
corsicanguppy@lemmy.ca
on 08 Aug 2024 14:27
nextcollapse
Fucking GENIUS.
acockworkorange@mander.xyz
on 14 Aug 2024 23:39
collapse
I don’t get it.
Boomkop3@reddthat.com
on 08 Aug 2024 15:12
collapse
I love it
xcjs@programming.dev
on 08 Aug 2024 14:06
nextcollapse
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. 😅
possiblylinux127@lemmy.zip
on 08 Aug 2024 15:28
nextcollapse
.internal takes to long to type
xcjs@programming.dev
on 08 Aug 2024 15:30
collapse
I used to use .local but mDNS can get confused, .home has been fine though
Wilzax@lemmy.world
on 09 Aug 2024 02:36
nextcollapse
Why do I care what ICANN says I can do on my own network? It’s my network, I do what I want.
ygpa@lemmy.world
on 09 Aug 2024 02:44
nextcollapse
YouCANN do anything you want?
Voroxpete@sh.itjust.works
on 09 Aug 2024 03:44
nextcollapse
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.
torkildr@lemmy.world
on 09 Aug 2024 18:21
collapse
Interesting that you should use “.local” as an example, as that one’s extra special, aka Multicast DNS
friend_of_satan@lemmy.world
on 09 Aug 2024 11:00
nextcollapse
Try using .com for your internal network and watch the problems arise. Their choice to reserve .internal helps people avoid fqdn collisions.
Wilzax@lemmy.world
on 09 Aug 2024 15:11
nextcollapse
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
friend_of_satan@lemmy.world
on 09 Aug 2024 15:25
nextcollapse
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.
Ah good point. I guess a future-proofed guarantee that the domain will never be used externally would be easier to use than trying to somehow configure my DNS to never update specific addresses.
DarkMetatron@feddit.org
on 09 Aug 2024 18:15
nextcollapse
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.
aesthelete@lemmy.world
on 09 Aug 2024 18:37
collapse
I agree that this is a good idea, but I wanted to add that if someone owns a domain already, they can also use that internally without issue.
If you own a domain and use Let’s Encrypt for a star cert, you can have nice, well secured internal applications on your network with trusted certificates.
witten@lemmy.world
on 09 Aug 2024 18:41
nextcollapse
You don’t even need a star cert… The DNS challenge works for that use case as well.
aesthelete@lemmy.world
on 09 Aug 2024 18:43
collapse
I agree, if you’re putting your internal domain names into the public DNS you do not need a star cert.
emptiestplace@lemmy.ml
on 09 Aug 2024 18:47
collapse
No, you don’t need to do that.
aesthelete@lemmy.world
on 10 Aug 2024 00:27
collapse
Maybe I’m missing something then, how would you pass a DNS challenge?
DarkMetatron@feddit.org
on 10 Aug 2024 07:19
collapse
That is great when using only RFC 1918 IPv4 addresses in the network, but as soon as IPv6 is added to the mix all those internal only network resources can becomes easy publicly available and announced.
Yes, this can be prevented with firewalling but it should be considered.
patrick@lemmy.jackson.dev
on 10 Aug 2024 02:47
collapse
If you just run a personal private network, then yea pick anything because you can change it fairly easily. Companies should try to stick to things that they know won’t change under them just to avoid issues
threaded - newest
It would have been nice if they came up with something shorter like .lan.
Use it anyway.
You go to networking jail for that.
Shit, let’s hope the ICANN cops don’t find me out then… I’ve been using it for years!
“I hereby sentence you to two years on your own VLAN with no gateway”
“Please Mr. Router, mercy!”
iptables -I APPEALS -j DROP
418
Lowercase .lan uppercase .LAN…
Straight to jail
Error 418
Oh, that’s LAN - I thought you’d put ian and I was trying to get the joke. Stupid sans-serif fonts.
First pictures of him sleeping now he has a TLD
That’s good, I never liked the clunky
.home.arpadomain.Well, I just realized I completely goofed, because I went with .arpa instead of .home.arpa, due to what was surely not my own failings.
So I guess I’m going to be changing my home’s domain anyway.
It was just always so annoying having to go into the iPhone keyboard punctuation twice for each domain
I guess no one offered anything for .internal
Browsers barf at non https now. What are we supposed to do about certificates?
You can set up your own CA, sign certs and distribute the root to every one of your devices if you really wanted to.
Yeah I know about that, I’ve done it. It’s just a PITA to do it even slightly carefully.
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.
For self hosting at least, having your own CA is a pain in the ass to make sure everything is safe and that nobody except you has access to your CA root key.
I’m not saying it’s not doable, but it’s definitely a lot of work and potentially a big security risk if you’re not 100% certain of what you’re doing.
Just use only VPN to access your services behind the reverse proxy, if you want prevent unauthorised connections.
CA certificates are not here to prevent someone accessing a site, they are here, so that you can be sure, that the server you are talking to is really the one belonging to the domain you entered and to establish a tunnel in order to send the API calls (html, css, javascript etc.) and answers encrypted.
That’s the problem, if anyone somehow gets your root CA key, your encryption is pretty much gone and they can sign whatever they want with your CA.
It’s a lot of work to make sure it’s safe in a home setup.
You can just issue new certificates one per year, and otherwise keep your personal root CA encrypted. If someone is into your system to the point they can get the key as you use it, there are bigger things to worry about than them impersonating your own services to you.
And additionally, you can sign intermediate Certificates reducing the risk even more, since you can revoke and re-issue new ones any time.
No worse than protecting your ssh key. Just keep it somewhere safe.
As opposed to what, the domain certificate? Which can’t be air-gapped because it needs to be used by services and reverse proxies.
The domain certificate is public and its key is private? That’s basically it, if anyone gets access to your key, they can sign with your name and generate certificates without your knowledge. That’s my opinion and the main reason why I wouldn’t have a self hosted CA, maybe I’m wrong or misled, but it’s a lot of work to ensure everything is safe, only for a self hosted setup.
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.
I’m talking about home hosting and private keys. Not businesses with people whose full time job is to make sure everything runs fine.
I’m a nobody and I regularly have people/bots testing my router. I’m not monitoring my whole setup yet and if someone gets in I would probably not notice until it’s too late.
So hosting my own CA is a hassle and a security risk I’m not willing to put work into.
Yeah that’s your situation. Some people are fine with it
Ah, you mean they put the cert in a transparent proxy which logs all traffic? Neat idea, I should try it at home
They (the service that provides both web protection and logging) installs their own root certificate. Then creates certs for sites on demand, and it will route web traffic through their own proxy, yes.
It's why I don't do anything personal at all on the work laptop. I know they have logs of everything everyone does.
Either ignore like I do or add a self signed cert to trusted root and use that for your services. Will work fine unless you’re letting external folks access your self hosted stuff.
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.comand all yourhttps://whatever.lan.domain.comURLs 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 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
That’s if you have a regular domain instead of.internal unless I’m mixing something. Topic of thread is .internal as if it were something new. Using a regular domain and public CA has always been possible.
This is not a new problem, .internal is just a new gimmick but people have been using .lan and whatnot for ages.
Certificates are a web-specific problem but there’s more to intranets than HTTPS. All devices on my network get a .lan name but not all of them run a web app.
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
No one is saying it is their job.
Merely that using a TLD like .internal requires some consideration regarding ssl certificates.
But why are people even discussing that?
This is about an ICANN decision. TLS has nothing to do with that. Also you don’t really need TLS for self hosting. You can if you want though.
Because people can discuss whatever they like?
If you don’t like it just down vote it.
People can talk about whatever they want whenever they want. The discussion naturally went to the challenges of getting non-self-signed certificates for this new TLD. That’s all.
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.
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.
My set up is similar to this but I’m using wildcards.
So all my containers are on 10.0.0.0/8, and public dns server resolves *.sub.domain.com to 10.0.0.2, which is a reverse proxy for the containers.
.
Private CA is the only way for domains which cannot be resolved on the Internet
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?
You cannot buy .internal domains. That’s my point.
Accept them
Nothing, this is not about that.
This change gives you the guarantee that
.internaldomains 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..boxbecame available for purchase and someone boughtfritz.box, which broke browser UIs. This could’ve even been used maliciously, but thankfully it wasn’t.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
The main reason this will never happen is that the browser vendors make massive revenue and profit margins off of The Cloud and would really prefer that the core concept of a LAN just dies so you pay your rent to them.
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.
Makes ya wonder what else it’s doing that for…
So you can access your router’s config page without blasting your password in plaintext or getting certificate warnings. It’s an optional feature.
Same thing we do with .local - “click here to proceed (unsafe)” :D
Set up my work’s network waay back on NT4. 0 as .local cuz I was learning and didn’t know any better, has been that way ever since.
Thank god. Now iOS will finally recognize it
Interesting. I’ve been using “.home.arpa” for a while now, since that’s one of the other often used ways.
Yes, I’ve been using this too. Here’s the RFC for .home.arpa (in place of .home): www.rfc-editor.org/rfc/rfc8375.html
Nice. Thanks 👍
No problem!
We use .lh, short for localhost. For local network services I use service discovery and .local. And for internal stuff we just use a subdomain of our domain.
Sorry. I chose .local and I'm sticking to it.
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.
That I agree with. Microsoft drafted the recommendation to use it for local networks, and Apple ignored it or co-opted it for mDNS.
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?
.local is already used by mDNS/Zeroconf.
You mean mDNS/Zeroconf are using a tld that was already being used.
Tell me you don’t share a net with Macs without using those words.
Macs aren’t the only thing that use mDNS, either. I have a host monitoring solution that I wrote that uses it.
Even on windows sometimes depending on the target host, I’ve had to type host.local. (Final dot to do exact match) instead of host.local
This didn’t seem to affect other domains. I’m assuming it was due to special handling of .local
mDNS hasn’t been a just-Apple thing for decades. Do you still call it Ren-dess-voos like the Gaston character in Beauty and the Beast?
My main issue was it doesn’t play well with Macs.
I went with .home and so far the problems are within reason
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.)
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 switched from .local to .honk and I’m never looking back.
Fucking GENIUS.
I don’t get it.
I love 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. 😅
.internal takes to long to type
Yeah, that’s why I started using .lan.
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
Oh. Internal hosts, I just setup on my own DNS.. No need for that. Printer, can't say I've ever had a problem.
I’ve had issues with .local on my Android device. Straight up doesn’t work. I had to change to .lan
Hmm, the only issue I had was because it was using the DoH (which I don't have a local server for). Once I disabled that, it was fine.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
6 acronyms in this thread; the most compressed thread commented on today has 6 acronyms.
[Thread #910 for this sub, first seen 8th Aug 2024, 09:05] [FAQ] [Full list] [Contact] [Source code]
Took long enough
I will stick with .lan
But what if your name is not Ian…
Then change it Ian!
Tai’shar Malkier!
It should be reserved for sex toys.
Just saying.
What are you doing step-LAN?
Please don’t use the duplex again.
I saw you peeked inside my ssh key drawer last night step-LAN
I used to wonder why porn sites aren’t required to use ‘.cum’ instead of ‘.com’…
The original 3, “.cum”, “.nut”, and “.orgasm”.
Ah yes, the golden
showerage of the web.Well did you find out?
some sex toys are external
Then they go on .external, obviously.
Its just a redirect loop from .internal to .external and back.
man mountThanks but I hardly needed anyone permission to not use that. .local still works just fine.
Except when it doesn’t. It can have issues around multicast dns.
I’ve had issues with .local on my Android device. Straight up doesn’t work. I had to change to .lan
Same here, just stumbled across this issue yesterday when I tried to restructure my network to use .local
I think it was only added in android 12.
It just means .internal won’t be relayed out on the internet, as it will be reserved for local only.
Good luck with that. .local is reserved for mDNS calls, and not every OS treats it the same way. Ask me how I know.
Been working fine for me for twenty years or more in a mixed environment.
I used to use .local but mDNS can get confused, .home has been fine though
Why do I care what ICANN says I can do on my own network? It’s my network, I do what I want.
YouCANN do anything you want?
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
Try using .com for your internal network and watch the problems arise. Their choice to reserve .internal helps people avoid fqdn collisions.
See also traintocode.com/stop-using-test-dot-com/
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.
Ah good point. I guess a future-proofed guarantee that the domain will never be used externally would be easier to use than trying to somehow configure my DNS to never update specific addresses.
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.
I agree that this is a good idea, but I wanted to add that if someone owns a domain already, they can also use that internally without issue.
If you own a domain and use Let’s Encrypt for a star cert, you can have nice, well secured internal applications on your network with trusted certificates.
You don’t even need a star cert… The DNS challenge works for that use case as well.
I agree, if you’re putting your internal domain names into the public DNS you do not need a star cert.
No, you don’t need to do that.
Maybe I’m missing something then, how would you pass a DNS challenge?
That is great when using only RFC 1918 IPv4 addresses in the network, but as soon as IPv6 is added to the mix all those internal only network resources can becomes easy publicly available and announced. Yes, this can be prevented with firewalling but it should be considered.
If you just run a personal private network, then yea pick anything because you can change it fairly easily. Companies should try to stick to things that they know won’t change under them just to avoid issues
.
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.
the only losers in this situation are people that are squatting on my rightfully pirated domain names!
Missed the opportunity for
.myshit.Next up!
ICANN approves use of
.awesome-selfhosteddomain for your networkWoohoo! We internal now! No more FQDN collisions!
routerlogin.net how I do not miss you
i loved that it was an option. not sure why it was changed.
I personally use .nexus for my network.
My network is .milkme and I have nipples… will they approve it?
You can milk anything with nipples!