It' looks to me like ".home", ".corp", and ".mail" were reserved as "high-risk", and then they refused to approve any of them as gTLDs.
I see an argument that ".dev" should have been considered "high-risk", but it doesn't seem to have been on the list. So this isn't a reason to distrust ICANN when they say they won't be approving ".home", ".corp", and ".mail".
People were using .dev as an internal tld thinking that it'd never become a "real" tld, and they were using that for years. Now though it's a real tld and that opens up many conflicts.
I'd add that .dev was never a safe TLD, it just wasn't available yet.
Using .dev was a pretty foolish thing to do, and ICANN making it available shows how important it is to use proper TLDs for intranets. (That said, a case could be made for .dev being classified as high-risk.)
- HSTS forced by default by Chrome, sorry if you wanted to use http://yourdomain.dev, HSTS forces HTTPS.
- If you have a self signed cert (like Traefik or Caddy for local HTTPS dev), you will get the "not valid cert" browser warning, that one that in any other TLD you know more than your browser and click the "ignore warning and let me use the website", with .dev that button does not exist.
I've never seen .email in the wild or on a LAN. If it was for servers, wouldn't email-server.local, .lan, .home, .corp, etc. make more sense? And using it as a part of an address like me@server.email seems redundant.
I'd need to self-sign my certificates, right? So any guests in my house (assuming a modern browser) would be presented with a big ugly security warning after navigating to a local home.arpa site?
I pay $10/year for a custom domain on my country's TLD and host any local stuff on that, so I can use proper CA-signed certificates which are trusted by default. But I could see this being useful if I was only using my own clients.
I use it for all my devices. But obviously if you want to host a service with TLS, even an internal one, use a real domain. .home.arpa is only the device hostname, not the service name.
It's a lottery with these novelty TLDs. If you use them, setup your configuration such that you can move to another TLD easily.
.nets and .coms increase in price too, but they don't tend to jump by 100% in a single year like these novelty ones, which were created purely to make money for the registry.
That's what I did with a couple .uk domains from Cloudflare. I bought ten years at $4.30 per year so I don't have to worry about renewal price increases for a long time. I also liked that it was suck a short TLD and not from some sketchy country.
I spend way more in a bar in one night than on my domains yearly, so I always find 'oh I need one super-duper cheap, below $2/y otherwise it's way too much' comments a bit.. too frugal.
I also spend more in a bar in one night than on charging my phone for whole year. If the cost to charge it went up by 10x I would still be displeased though.
> If the cost to charge it went up by 10x I would still be displeased though.
Sure anyone would be, but... maybe don't choose .furniture[0] as the TLD for your own small private LAN DNS and don't have the unpleasant surprises?
The prices for the registrations (and renew) are going up steadily (just like everything else? inflation is a thing), but there is always an option to get the information about the renewal price upfront and maybe even use the multi-year sale.
Just looked in Dynadot's CSV, there are ~100 TLDs with sub $10 renewals and additional ~100 with < $15.
Also dug my records[1], privacy is baked in now, so the total effective rise is $1 for `.one` and... -$2 for `.com`.
While I personally would stick to reputable TLDs for anything you want to keep I still think that a 10x price increase on any TLD is super sketchy, especially when it isn't communicated up-front to buyers. My comment was just about those super high rises that to me feel like they are exploiting people who can't easily switch. It was not intended to be about slight price adjustments to match inflation, rising operating costs and the like.
The real question is: Why should people have to pay to some registrar for an internal-use only home network anyway just to avoid nasty security warnings – even if it's not very much by the somewhat dubious benchmark of "cheaper than a night of drinking"?
You always have an option to run an internal PKI, without paying anyone.
The public PKI is built on the public DNS system. If you want a cert to be trusted by default and don't want to bother with your own internal PKI then you need to leverage the existing public infrastructure, which doesn't give it away as a free beer but sells it.
Have you tried that with various devices these days? It's getting increasingly difficult to convince various mobile OSes to accept internal root CAs (largely for good reasons, but that's a different discussion).
> you need to leverage the existing public infrastructure, which doesn't give it away as a free beer but sells it.
No, it's the opposite these days. The existing PKI these days is free (Letsencrypt and others), but getting a public domain that any browser-acceptable CA will issue certificates for isn't. Your domain registration/renewal fees don't pay for that PKI.
I think it's urgently needed for browser vendors, the IETF etc. to get together and figure out a solution for accessing "mymediocreiotdevice.home" without a barrage of "zomg no HTTPS!!", "zomg self-signed cert!" etc. warnings, as these will only desensitize users further to actual problems on publicly-accessible sites.
This is what I said in the first place - public DNS is not free. The costs to get in range but the minimal isn't that much ($5/year to be precise), so the question is between any amount at and no at all.
It’s more the principle of the thing… if I buy a domain for $3 and it’s $30 next year, I’m just going to switch my stuff over to .com or .net where the price is predictable.
I did this for a while back when freenom existed. Then, I moved and learned that I was exceptionally lucky to have working loopback NAT in my previous house, and would have to split off a local.<domain> entry for clients on the internal network. No idea why most ISPs don't have routers that work like that.
I haven't bothered doing DNS auth to get certs since I started using paid domains.
i still dont understand why 192.168.20.1 should show as insecure. or abc.local that points to 192.168.0.22. why should i need a certficate for that and what "security" is there to begin with? if a threat actor is in my lan, what hope do i have of https?
Two security concepts come to mind: defense in depth and assume breach. A hacked device on your lan doesnt have to equal complete compromise of your betwork. Giving up at the perimeter is one option, sure. Another is to design a network to be as resilient as possible to attack and compromise by layering defensive controls and assuming some can be bypassed. Then develop detective/preventative controls to respond when they are.
Edit: specifically, encrypting http traffic will help reduce the risk of the threat actor acquiring new credentials (since we don't reuse those) and using them to pivot to other resources.
Let’s see.. I assume the warning serves two purposes:
1. You may be talking to someone other than you think. This only makes sense with registered domain names.
2. Your data can be eavesdropped or modified by someone in the middle. This would be quite rare within a LAN. Encryption itself might make sense sometimes but standard TLS is a really poor fit because there is no proper CA for the domain names.
The main issue though is people don’t want IP addresses, they want names. If a special domain (like .home or .local) will only ever query local DNS servers returning local IP addrs, it would be roughly as safe as using IP addresses directly(?).
In either case, when the user intentionally wants to speak over LAN (either IP or known home domain) the warning is unhelpful. For instance, configuring a router.
> Your data can be eavesdropped or modified by someone in the middle. This would be quite rare within a LAN
Literally every single public wifi network, which is a significant percentage of all internet traffic (including basically everyone working from a wework for example), is vulnerable to eavesdropping/mitm
That’s true and should have been phrased differently. But names and addresses within a public LAN rarely have meaning to the customers, I guess. Btw, can an adversary on such a lan typically spoof source IPs and eavesdrop on packets between other nodes? I realize I know very little about WiFi.
> Btw, can an adversary on such a lan typically spoof source IPs and eavesdrop on packets between other nodes?
Yes, or no. It's possible, and with the right lan equipment trivially easy to prevent this, however you can't tell from the outside if the network is set up this way or not so you have to assume it isn't.
Thanks for the info. I remember that 10-15y ago there were these snoopers you could install (perhaps a Firefox extension - I remember it was very easy) to steal session cookies from Facebook users in the same public WiFi’s. After that SSL by default – previously deemed “too expensive” for Facebook – was deployed rapidly, never to be mentioned again. So it sounds like WiFi too has improved then.
There was a also proposal for ICANN to reserve ".internal" (earlier this year) which is what I currently use. I suppose home.arpa has the advantage of being strictly resolved in the local zone while ".internal" would be more for anything in a private network (or a large multi zone network)?
The inability to get a TLS cert is an issue. I've been working on getlocalcert [1] as a free subdomain service for local networks. You get a valid domain, you can get a Let's Encrypt (or other ACME DNS-01 provider) cert. But you need to provide your own split DNS locally to resolve addresses. It's intended to fill the gap between paying for a domain or using a free domain service full of abuse.
Because you need to provide DNS locally, it's useless for the common abuse scenario (spam, phishing, illegal content). Unlike other free domain providers, I have never received an abuse notification.
I got on the public suffix list in the last few months. Lots more features I'd like to add, but my attention has been elsewhere.
I was just looking into this kind of thing for a training lab we stood up and maybe you could have some advice/clarification to offer me from working on this. We have a locally hosted external DNS which wildcards everything not otherwise specified to an authenticating web proxy (currently caddy and locally hosted coredns). It's not clear what the "lazy" way to get a wildcard DNS cert via ACME DNS challenge going is with this kind of set up. To me it feels like Caddy is missing a built in functionality to act as the delegated ACME DNS responder and it's not clear which option is the best way to get Caddy (normally very automatic) to reload after it handles the requests.
Not particularly bound to Caddy or Coredns on the external side but it's what we're using for the internal as well.
Are you trying to get the TLS cert for domains you own, or are you getting certs for all other domains?
For the former, the Caddy ACME DNS plugin should work.
For the latter, I think mitmproxy or similar would handle the on demand TLS cert creation. There's commercial intercept proxies as well, but I have no experience with them.
I've thought about running a local CA, but wouldn't one need to have all of their devices configured to trust the local CA in addition to issuing certs to your services? I've been getting by just clicking through the TLS warnings for my LAN services, most browsers remember the choice for a couple days at least.
It's a bit of a pain to load a cert onto every device (easier with stuff like Ansible if you have a bunch of linux devices), but manageable. And it lets me do proper trusted TLS for a lot of stuff that would otherwise be self-signed.
edit: It's also just a fun homelab project to see what it's like to run a full production-ish PKI setup.
One thing I recommend is to add X509v3 Name Constraints extensions to your root CA if you go down this path. It prevents the CA from being abused to MITM you for other domains (at least for browsers/clients that respect names constraints)
X509v3 Name Constraints: critical
Permitted:
DNS:home.arpa
DNS:.home.arpa
IP:10.0.0.0/255.0.0.0
IP:172.16.0.0/255.240.0.0
IP:192.168.0.0/255.255.0.0
it depends on your use case, but yes you would probably need to load at least your browser with your own CA. It’s a good hygiene to manage your own keys though
I’m holding out for a draft RFC to deprecate .local for mDNS, and allow it to be used for local domains. It’s practically infeasible, but one can wish.
Same here. We set up our company's intranet using a `.local` address long before mDNS was a thing. Needless to say it causes a lot of pain on a daily basis.
On almost every linux installation we have to tweak `/etc/nsswitch.com` for it to work.
I doubt it'll ever happen but hey, one can wish :)
Given the fact that Kubernetes uses cluster.local. by default (and probably in the 99% of clusters), you can be sure that any useful software will be OK with that.
Kubernetes is normally used on hosted servers and mDNS is normally used for home appliances like printers. I wouldn’t expect Kubernetes to be able to show that using .local is safe with mDNS.
My Verizon FIOS router came with the ridiculous default domain "mynetworksettings.com". I haven't changed it yet, because I wasn't sure about .local vs .home and whether changing it would break something. As an OG ARPANET user, I rather like the idea of having a home "arpanet" so I think I'll give home.arpa a try!
I've used it at home for several years as well, works great. Due to reasons I've used another level to separate services, management, clients and iot (iot.home.arpa, services.home.arpa...) which I kinda regret today.
Exactly this; I don't care how much more "correct" home.arpa is, I'll keep using my .lan thank you very much. They really need to just go ahead and officially reserve a nice shorthand TLD for local networks. .lan is already frequently used in internal networks and wouldn't have much appeal as a general-purpose TLD anyway.
Surely you'd only ever have an issue if your name collided? If you never have a router.local using mDNS the existence of a DHCP-registered hostname in that form won't matter? And if it did collide you just might not get what you expected?
Hmm, my local dns servers, adguard and dnsmasq don't seem to recognize it. Do I have to configure something? I prefer the .lan that I'm currently using.
Seriously, I run ARPA-NET in my home.internet, as well as IPX (Bayans VINES) and Frame Relay/X.25. Yeah, it's what I do. Also encrypted MAC-layers too.
Now the real kicker is maintaining DNSSEC for my home.internet. A real exercise in extremity (but not futility yet it is doable)
The issue with this is that you can't create certificates this way.
Assume you own example.com, then you can issue a free certificate for *.example.com and use that certificate for all your home services. Using HTTPS in the intranet does have its benefits and eases coding when services require SSL.
If you host vaultwarden.example.com in your intranet, then you don't have to publish the subdomain on a public nameserver; it's enough that your intranet DNS resolver can respond with the local A or AAA record for vaultwarden.example.com and it's covered by the wildcard certificate.
Is it possible to limit the CA to only cover certain domain, e.g. *.yourown.home.arpa? Or is it the case that if you install a CA of your friend, it grants them the possibility of MitMing most any service (with non-pinned cert), at least when enabled by network topology?
I've been using a local CA for a long time, but I have not found a way to limit it that way, so security-wise it is less than optimal.
Friends don't ask friends to install their custom root CA. If someone asked you to install theirs, would you?
After all, once they've installed your root CA, you'll now be able to trivially intercept all of their encrypted HTTPS communications while they use your network. I wouldn't trust my mother with that power.
Specifically, what I mean is, if you have house guests that care enough about your LAN that they actually want to access any of the services you have running on it – it shouldn't be difficult to explain to them why and how to trust your CA.
The main difficulty IME is getting any of your guests to care about your LAN services in the first place.
I'm sorry, but if you ask me to install your private CA on any of my devices... I would politely tell you to stop.
As for house guests, I really like what OnHub did - you could allow anyone to network to control certain IoT devices. When someone was house sitting for me, they could have control thermostat, lights, etc from their phone without any apps or "add household member" shenanigans.
> allow anyone to network to control certain IoT devices
Yeah that makes sense :)
My own house is not really IoTified yet. I have a single "smart" plug that I can turn on or off with an app that the night table lamp on one side of the bed is plugged into. But I could see the appeal of having the IoT setup accessible to guests for people that have more IoT stuff in their house.
When you're a guest at a friend's house, for example, you would have no problem installing their root CA in exchange for the privilege of using their network? Wouldn't you find that to be a little bit antisocial or overbearing?
I can just link people from home.com to a page with an ssl cert if it became necessary for some reason. I'm curious what benefits you're thinking using HTTPS on my intranet would have (other than circumventing increasingly overzealous browser vendor API lockdowns)
(on that note, is there a chromium/firefox build available that disables all that garbage so I can test in peace without having to reverse proxy my dev server?)
Preventing other users on your network from snooping the administrative credentials to your LAN services for one (easy to do on WiFi, even if you use WPA). Also, if one of your devices switches off your WiFi and onto cellular, and you are using basic authentication, you are not only sending your credentials to whoever owns home.com, but also doing so in plain text. If you did that on some public wifi, that could get picked up by someone snooping. Sure, they wouldn't know where your services are, but why put a crack in your security when you don't need to?
> I can just link people from home.com to a page with an ssl cert if it became necessary for some reason
The only way that would work is if you use a root certificate authority and have them install it as trusted in their device, which is asking them to compromise their security, because that authority will be trusted for all TLS validation on any domain.
> Preventing other users on your network from snooping the administrative credentials
well, the only credential is that they're on my network! though fwiw i think even if there were credentials people on my LAN snooping my creds is not part of my threat model i care about at all, same with sending them to whoever owns home.com
> why put a crack in your security
because security has a cost that you shouldn't pay unless it makes sense to
> The only way that would work is if you use a root certificate authority
no, i can just link to a domain i can get Let's Encrypt certs for
For your own devices and use (provided you can configure your devices to all use your local nameserver) you really don't need to care (unless you, at some point, want to make use of whatever the true owner is offering at "home.com").
But, for any visitors, if they have their devices configured to use their providers name servers, or if they have configured them to use one of the public name servers, if you direct them to "home.com" for something on your local lan, their device will instead resolve "home.com" to the IP assigned by the actual owner, and they will not be able to access your lan local "home.com" services.
Ref: https://www.icann.org/en/board-activities-and-meetings/mater...