Special-use domain 'home.arpa.' (2018) | Hacker News Reader

Special-use domain 'home.arpa.' (2018)

datatracker.ietf.org

126 pointsmcp_140 comments

`.home`, `.corp` and `.mail` are on ICANN’s “high risk” list so won’t ever be gTLDs. So I use those gTLDs when setting up internal networks.

Ref: https://www.icann.org/en/board-activities-and-meetings/mater...

They still let ".dev" go through

I'm still angry at them (and Google) for that

I'm more bummed about .zip becoming a TLD. I've already been bitten by it a couple times.

I straight up block *.zip domains at the firewall because of their use and abuse.

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".

The one I use is .lan.

They were only granted that gTLD because in their application they explicitly said they would never allow GA registrations.

Google did extreme evil with .dev, with the blessing of ICANN.

What’s wrong with .dev?

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.

And yet they let through `.email` ...what?

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.

Emirates airlines use .email as their email only domain for booking emails, but their customer service center emails comes from Emirates.com

ICANN's TLD application status page [1] is quite interesting. Like Google trying to get .corp [2].

[1] https://gtldresult.icann.org/applicationstatus/viewstatus

[2] https://gtldresult.icann.org/applicationstatus/applicationde...

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.

There's a ton of gTLDs too, I just grabbed a cheap one and ACME-fied all my lan services

Are there any that actually stay cheap, though? Any time I've bought one they've cranked the price after a year.

… .net? (<$15/y for the registration.)

The following TLDs are $3.98/yr (not an initial discount, that's just the price) with Cloudflare Registrar according to https://old.reddit.com/r/webdev/comments/17lpxa6/cloudflare_...:

  - .bid
  - .download
  - .date
  - .loan
  - .men
  - .party
  - .stream
  - .trade
  - .win

You could probably get away with using a few of these for a home network, though some would be kinda strange (.men? .loan?)

LOcal Area Network? Low Orbit Area Network?

For a small network; a router, a single server hosting stuff, an AP, and whatever wireless clients: Low On Actual Network.

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.

e.g. https://tld-list.com/blog/tld-wholesale-price-increase-2023

  TLD         Old     New     Percent  Date
  .reviews    $17.00  $40.00  135.29%  2023-10-04
  .furniture  $38.00  $80.00  110.53%  2023-10-04
  .faith      $4.98   $9.98   100.40%  2023-09-04
  .racing     $4.98   $9.98   100.40%  2023-09-04
  .review     $4.98   $9.98   100.40%  2023-09-04
  .science    $4.98   $9.98   100.40%  2023-09-04

Numerical 6 to 9 digit .xyz domains are 0.99 cents a year, $10 for 10 years.

…or alternatively simply buy a domain for 5 or 10 years.

Not all TLDs will let you do that.

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.

> they've cranked the price after a year.

Define 'cranked'.

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.

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 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`.

[0] https://news.ycombinator.com/item?id=40571805

[1]

    date created: 2015/08/20
    <placeholder>.com - domain renewal
    1 year ($10.99)
    <placeholder>.com - domain privacy
    1 year ($3.00)
    PAYMENT
    final cost:   $13.99

    date created: 2016/07/21
    <placeholder>.one - domain renewal
    1 year ($10.99)
    <placeholder>.one - domain privacy
    1 year ($3.00)
    PAYMENT
    final cost:   $13.99

    Date created: 2023/09/08
    <placeholder>.com - Domain Renewal
    1 year ($11.99) $11.99

    Date created: 2023/10/16
    <placeholder>.one - Domain Renewal
    1 year ($14.99) $14.99

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.

>No, it's the opposite these days

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.

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.

You.BEAUTY - https://data.iana.org/TLD/tlds-alpha-by-domain.txt

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.

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.

what about 12.0.0.1 cases?

> 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.

You can't always assume that 192.168.20.0/24 is your lan. Could be the local coffee shop, could be your neighbor's kid with a pineapple.

Can't you just not use a certificate? It's not on the HSTS preload list.

True, can host HTTP-only but that still surfaces a warning on modern browsers.

I get a small icon in the the URL bar indicating it, but nothing that the average person would even notice.

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)?

[1] https://www.icann.org/en/public-comment/proceeding/proposed-...

This proposal is still wending its way through ICANN's processes. It should finalize with an ICANN Board resolution sometime this year.

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.

[1] https://www.getlocalcert.net/

Sign your own? It’s your home!

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.

I've been doing this for a while with SmallStep CA: https://github.com/smallstep/certificates

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

At that point just buy a proper domain. That ought to be easier than setting up a custom CA.

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 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.

Just a *.ourpubliclabdomain.com cert. I'll look into ACME DNS + the Caddy plugin. Thanks!

A good way to avoid the Fritz.box issue from a few weeks ago https://news.ycombinator.com/item?id=40106336 / https://domainnamewire.com/2024/05/02/internet-gateway-compa...

For anyone else wanting to now how this turned out: https://www.heise.de/en/news/Schiedsverfahren-gewonnen-Domai...

For anyone else wanting to know how this turned out without clicking through popups in German: Fritz.box won against the new anonymous registrant.

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 :)

Your company is over twenty years old? Well done.

didn't realize that was something to point out ...

That will never happen, but RFC 6762 suggests some other options for private networks: .intranet, .internal, .private, .corp, .lan.

https://datatracker.ietf.org/doc/html/rfc6762#appendix-G

ICANN seems to be in the process of finalizing a proposal to officially reserve .internal for this purpose.

https://www.icann.org/en/announcements/details/icann-seeks-f...

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.

Kebernetes ought to change that default, as it's contrary to the standard.

e.g. systemd by default won't query DNS for a .local domain, and it's sometimes useful to connect to K8s resources from outside the cluster.

Just use mDNS then. But as others have said, there are other options that are almost as good.

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!

Hey, at least Verizon bothered to register the domain.

Reminds me of this story from last year:

https://www.caranddriver.com/news/a44083580/maryland-license...

ICANN has proposed using .internal; see https://news.ycombinator.com/item?id=39152306.

I use lan.urda.com for mine. Looooove having a public and private DNS record set.

I use this for everything at my house. I haven't add any issues.

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.

I use int.example.com for my home network, where example.com is a domain I've had for 30 years. Domains didn't cost anything back then!

This RFC is recommending a default, non-unique domain for residential routers to ship with.

If you have a domain of your own, by all means use it. Most residential network operators don't.

What exactly does that mean? 'example.com' is registered to IANA since 1992.

OC replaced the real domain with example.com. Could have used int.google.com.

It means grandparent commenter ain't sayin':

> where example.com is a domain I've had for 30 years

(That domain has that reservation specifically for use in arbitrary examples, as here.)

It was a placeholder... an example. (You know, the documented purpose of example.com!) I am not posting my actual domain here.

So public DNS contains records pointing to private IPs?

Yes. I could implement split DNS, but I don't.

There was a famous joke where someone pointed a subdomain to localhost and invited anyone to hack it.

I do the same with my personal domain. Combined with a wildcard cert, all my internal services are on valid certificates with ease.

That's cool, but it's ugly so I'm going to keep using a technically-incorrect-but-works-fine alternative

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.

just let us have .lan for lans please

I thought about going that route but ultimately decided to hijack .home internally for my home network.

.home is fine, but .local is used by mDNS like Bonjour. In practice, it doesn’t seem to cause much problems for printers and AirPlay.

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?

And how is .home.arpa better than RFC-2606 .test, .example, .invalid, or .localhost ?

Because devices on my home network aren't examples, aren't invalid, aren't (all) localhost, and aren't (necessarily) for testing.

What about devices on my work network? Is work.arpa a thing? Or are the labels arbitrary?

work.arpa is not a thing, but you could use .internal for corporate stuff.

At work best practice is to use a real domain you have control of both internally and externally.

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.

[RFC 8375]

https://home.arpa

DNS_PROBE_FINISHED_NXDOMAIN. Is it different at your end or why are you posting this?

Because, it is the INTERNET! (cough cough)

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)

I just use home.com for all my home automation stuff, it's a lot easier to explain to houseguests than home.home.arpa would be.

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.

> you can't create certificates this way

Sure I can. It's my network, so I decide what root CAs are trusted. Be your own CA, and tell your computers to trust your own CA cert.

For example:

https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi...

https://github.com/jsha/minica

Per GP, this will be VERY difficult to explain to houseguests.

Why?

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.

That's what I do, I just hijack home.com to do it and don't care about SSL on my intranet.

> 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.

And how are you going to distribute these certificates to your houseguests?

I run a plain http server on the LAN that hosts a copy of the public part of the CA cert. Download it from there and add it to your trusted CAs.

Please tell me your friends aren’t stupid enough to install random ca roots

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.

I blame lacking implementation of https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 by TLS clients.

Doesn’t even have to be the ones baked into the cert - I should be able to import a root to authenticate a list of domains that I specify.

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 don’t need to install their root CA unless I specifically want to access any LAN services.

Most people are not interested in that and so don’t need to add any new CA.

Most people borrow the WiFi so they can check their WhatsApp, Instagram, TikTok etc. None of which requires adding any new CA.

> I don’t need to install their root CA unless I specifically want to access any LAN services.

s/unless/even if/

No, I meant what I said.

Well, I guess you could deal with the TLS warnings instead.

But I prefer to install the CA cert so that the TLS connections are seen as valid.

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.

> Is it possible to limit the CA to only cover certain domain

Sure, via the Name Constraints extension.

Supposedly client support is spotty, but I have no experience in practice. Anything relatively modern could support it.

Thank you! I'll try that with my next CA, which I think is actually expired but it seems not all apps care about that :).

If "relatively modern" covers browsers and email clients, that's pretty good already.

edit: here's the reference: https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.... and here's a practical example: https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...

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

But you have to explain the insecure connections?

Why would they care? There's no reason to serve my home automation stuff over https.

Nor is there a reason to use a commercial domain.

But here we are.

Huh? home.com is a really simple easy to remember domain, that's a good reason isn't it?

And "home.com" is owned by someone, and registered through GoDaddy:

   Domain Name: HOME.COM
   Registry Domain ID: 1668509_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.brandsight.com
   Registrar URL: http://gcd.com
   Updated Date: 2022-04-09T03:55:51Z
   Creation Date: 1993-12-16T05:00:00Z
   Registry Expiry Date: 2031-12-15T05:00:00Z
   Registrar: GoDaddy Corporate Domains, LLC
   Registrar IANA ID: 3786
   Registrar Abuse Contact Email: abuse@gcd.com
   Registrar Abuse Contact Phone: +1.5189669187
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Name Server: NS2-02.AZURE-DNS.NET
   Name Server: NS3-02.AZURE-DNS.ORG
   Name Server: NS4-02.AZURE-DNS.INFO
   DNSSEC: unsigned

Not on my LAN it isn't! Why would I care who owns the domain?

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.

There is, for instance ESPHome requires to be over HTTPS to be able to flash ESP devices over USB.

Reply on news.ycombinator.com