Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.INTERNAL is now reserved for private-use applications

icann.org

Post reply on HN
Print view View original

191–200 of 290 posts

Re: .INTERNAL is now reserved for private-use applications

#191

Post by 0l »

hsbauauvhabzb wrote: post #176
0l wrote: post #158

Earlier quoted context omitted.

Use HSTS, browsers are specifically designed not to let users bypass these.

Hsts forces encryption, it has no impact on certificate invalidity, at least to my knowledge.

Visit your .internal site -> website uses TLS cert signed by root CA that is preloaded on your device. Succeeds and HSTS flag is set.

Visit other .internal site -> uses TLS cert NOT signed by root CA that is preloaded on your device -> certificate error, and cannot be bypassed due to HSTS.

Re: .INTERNAL is now reserved for private-use applications

#193

Post by dsr_ »

PartiallyTyped wrote: post #183
cowsup wrote: post #172

Earlier quoted context omitted.

.com is not a full word either (company), or .org (organization), .net (internet), .gov (government), ...

I thought .com was for "commercial".

.com is for .com. You can interpret it any way you'd like and it doesn't make a difference to anyone who isn't currently interested in the history of DNS.

My preferred reading is .com for commonlymisinterpretedbypeoplewhodonotreadrfcsbutitdoesnotmatterintheslightest, which is a Welsh word meaning "oddly shaped sheep".

Re: .INTERNAL is now reserved for private-use applications

#194

Post by [deleted] »

candiddevmike wrote: post #36
jeroenhd wrote: post #19

Earlier quoted context omitted.

.local is in this weird state where it's _technically_ not reserved, but most PCs in the world already resolve it with special non-DNS software because of the Bonjour/mDNS protocol. So you end up with the IETF standardising .local, because Apple was already using it, but ICANN never did much with that standardisation. I doubt ICANN will actually touch .local, but they could. One could imagine a scheme where .local is…

It's reserved per RFC 6762: > This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local. https://datatracker.ietf.org/doc/html/rfc6762 Applications can/will break if you attempt to use .local outside of mDNS (such as systemd-resolved). Don't get upset when this happens. Interesting fact: RFC 6762 predates Kubernet…

[deleted]

Re: .INTERNAL is now reserved for private-use applications

#195

Post by briHass »

jcrites wrote: post #24

Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com? It's nice that this is available, but if I was building a new system today that was internal, I'd use a regular domain name as the root. There are a number of reasons, and one of them is that it's incredibly nice to have the flexibility to make a name visible on the Internet, even if it is c…

I just got burned on my home network by running my own CA (.home) and DNS for connected devices. The Android warning when installing a self-signed CA ('someone may be monitoring this network') is fine for my case, if annoying, but my current blocker is using webhooks from a security camera to Home Assistant.

HA allows you to use a self-signed cert, but if you turn on HTTPS, your webhook endpoints must also use HTTPS with that cert. The security camera doesn't allow me to mess with its certificate store, so it's not going to call a webhook endpoint with a self-signed/untrusted root cert.

Sure, I could probably run a HTTP->HTTPS proxy that would ignore my cert, but it all starts to feel like a massive kludge to be your own CA. Once again, we're stuck in this annoying scenario where certificates serve 2 goals: encryption and verification, but internal use really only cares about the former.

Trying to save a few bucks by not buying a vanity domain for internal/test stuff just isn't worth the effort. Most systems (HA included) support ACME clients to get free certs, and I guess for IoT stuff, you could still do one-off self-signed certs with long expiration periods, since there's no way to automate rotation of wildcards for LE.

Re: .INTERNAL is now reserved for private-use applications

#196

Post by pas »

layer8 wrote: post #188
8organicbits wrote: post #46

My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess. Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of t…

I don’t understand the frustration. The use of .internal is explicitly for when you don’t want a publicly valid domain. Nobody is forcing anyone to use .internal otherwise.

the frustration comes when non-corporate-provisoned clients get on the .internal network and have trouble using the services because of TLS errors (or the problem is lack of TLS)

and the recommendation is to simply do "*.internal.example.com" with LetsEncrypt (using DNS-01 validation), so every client gets the correct CA cert "for free"

...

obviously if you want mTLS, then this doesn't help much. (but still, it's true that using a public domain has many advantages, as having an airgapped network too)

Re: .INTERNAL is now reserved for private-use applications

#197

Post by cloudyporpoise »

endorphine wrote: post #156
amelius wrote: post #155

Of course, scammers will register variations of .internal Like .lnternal Or .ιnternal

How? Do these gTLDs even exist?

they don't. This person must believe anyone can create and register any TLD lol

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

Re: .INTERNAL is now reserved for private-use applications

#198

Post by yjftsjthsd-h »

briHass wrote: post #195
jcrites wrote: post #24

Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com? It's nice that this is available, but if I was building a new system today that was internal, I'd use a regular domain name as the root. There are a number of reasons, and one of them is that it's incredibly nice to have the flexibility to make a name visible on the Internet, even if it is c…

I just got burned on my home network by running my own CA (.home) and DNS for connected devices. The Android warning when installing a self-signed CA ('someone may be monitoring this network') is fine for my case, if annoying, but my current blocker is using webhooks from a security camera to Home Assistant. HA allows you to use a self-signed cert, but if you turn on HTTPS, your webhook endpoints must also use HTTPS…

> Once again, we're stuck in this annoying scenario where certificates serve 2 goals: encryption and verification, but internal use really only cares about the former.

Depending on your threat model, I'm not sure that's true. Encryption without verification prevents a passive observer from seeing the content of a connection, but does nothing to prevent an active MITM from decrypting it.

Re: .INTERNAL is now reserved for private-use applications

#199

Post by amelius »

cloudyporpoise wrote: post #197
endorphine wrote: post #156

Earlier quoted context omitted.

How? Do these gTLDs even exist?

they don't. This person must believe anyone can create and register any TLD lol https://data.iana.org/TLD/tlds-alpha-by-domain.txt

Then why does .americanexpress exist?

Sounds like someone simply pulled their wallet.

Or maybe you forgot "/s"

Re: .INTERNAL is now reserved for private-use applications

#200

Post by pas »

kevincox wrote: post #170
fulafel wrote: post #126

Earlier quoted context omitted.

Yep, ambiguous addressing doesn't save you, same as 10.x IPv4 networks. And one day you'll need to connect or merge or otherwise coexist with disparate uses if it's a common one (like in .internal and 10.x)...

IPv6 solves this as you are strongly recommend to use a random component at the top of the internal reserved space. So the chance of a collision is quite low.

there's some list of ULA ranges allocated to organizations, no?

edit: ah, unfortunately it's not really standard, just a grassroots effort https://ungleich.ch/u/projects/ipv6ula/

Post reply on HN