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

111–120 of 290 posts

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

#111

Post by Jerrrrrrry »

nine_k wrote: post #69
TheRealPomax wrote: post #61

Earlier quoted context omitted.

to be fair, ".dev" is not a full word, unlike INTERNAL or EXAMPLE. You're free to petition them to reserve .DEVELOPMENT, though, of course.

A convenient TLD is short, not excruciatingly loquacious. In ease of typing .dev certainly wins over .development.

It's not convenient if 99% of users (internet users) can't (effectively) use it.

.dev is great; even if Google's motives were evil-truistic; and, *.development should be among the Reserved, Internet Use only.

The abbreviated vs verbose TLD name is consistence.

There aren't any folks more appreciable than consistency then the RFC goons.

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

#112

Post by thebeardisred »

nox101 wrote: post #76
ghshephard wrote: post #52

Earlier quoted context omitted.

Number one reason that comes to mind is you prevent the possibility of information leakage. You can't screw up your split-dns configuration and end up leaking your internal IP space if everything is .internal. It's much the same reason why some very large IPv6 services deploy some protected IPv6 space in RFC4193 FC::/7 space. Of course you have firewalls. And of course you have all sorts of layers of IDS and air-gaps…

What about things like cookies, storage, caching, etc.. If my job has ` https://testing.internal ` and some company I visit also has ` https://testing.internal ` ...

May god have mercy on the person using this in their mobile applications.

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

#113

Post by thebeardisred »

bawolff wrote: post #45
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 think there is a benefit that it reduces possibility of misconfiguration. You can't accidentally publish .internal. If you see a .internal name, there is never any possibility of confusion on that point.

Additionally how do you define publish?

When someone embeds https://test.internal with a cert validation turned off (rather then fingerprint pinning or setting up an internal CA) in their mobile application that client will greedily accept whatever response is provided by their local resolver... Correct or malicious.

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

#114

Post by Helmut10001 »

prussian wrote: post #104
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…

Just be mindful that any certs you issue in this way will be public information[1] so make sure the domain names don't give away any interesting facts about your infrastructure or future product ideas. I did this at my last job as well and I can still see them renewing them, including an unfortunate wildcard cert which wasn't me. [1] https://crt.sh/

Just use wildcard certs and internal subdomains remain internal information.

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

#115

Post by oasisbob »

dboreham wrote: post #87
jeroenhd wrote: post #71

Earlier quoted context omitted.

It does! I generally assume mDNS to just be available on every device these days. But I've also seen managed environments where mDNS has been turned off or blocked at the firewall.

mDNS is a broadcast protocol so always "blocked at the firewall ".

Multicast too. If you've never needed to manipulate ACLs for multicast traffic, you're not really living.

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

#116

Post by mrkstu »

nox101 wrote: post #76
ghshephard wrote: post #52

Earlier quoted context omitted.

Number one reason that comes to mind is you prevent the possibility of information leakage. You can't screw up your split-dns configuration and end up leaking your internal IP space if everything is .internal. It's much the same reason why some very large IPv6 services deploy some protected IPv6 space in RFC4193 FC::/7 space. Of course you have firewalls. And of course you have all sorts of layers of IDS and air-gaps…

What about things like cookies, storage, caching, etc.. If my job has ` https://testing.internal ` and some company I visit also has ` https://testing.internal ` ...

I'm assuming you wouldn't import their CA as authoritative just to use their wifi...

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

#117

Post by ninkendo »

quectophoton wrote: post #34
tetris11 wrote: post #5

I need a dumbed down version of this.

When you need to assign an IP address for a host, the safest thing to do is to either use an IP address you own^Ware renting, or to use an IP address nobody will be able to "own" in the foreseeable future. This is that but for domain names. When you need to use a domain name to refer to a host, the safest thing to do is to either use a domain name you own^Ware renting, or to use a domain name nobody will be able to "…

There’s similar discussions about this in other threads, but I’ve taken to just using a real domain name (lan..me) even for my house stuff, but otherwise doing something like you say above.

The advantage is that I can run real letsencrypt certs for services in my house, which is nicer than having to agree to self signed cert warnings or otherwise having my browser nag me about plaintext passwords/etc.

If anyone cares about the details, I run an nginx instance on port 80 through an ipv6 address which I allow through my network firewall (no NAT, so I don’t have to burn my only incoming ipv4 port 80 for this, although I block that anyway) and let certbot manage its configs. Wildcard external dns pointing AAAA records to said v6 address. The certbot vhost just renders an empty 404 for all requests except for the ACME challenges, so there’s nothing being “leaked” except generic 404 headers. I get certs dumped to my nginx config dir, then from there I use them for an internal-only reverse proxy listening on my local subnet, for all my internal stuff. The only risk is if I mess up the config and expose the RP to the internet, but so far I haven’t managed to screw it up.

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

#118

Post by eddyg »

csdreamer7 wrote: post #4

Can we get .local or .l added for private-use applications too?

.home, .corp and .mail are on ICANN’s “high risk” list so won’t ever be gTLDs, so they are also good (short) options.

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

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

#119

Post by Terr_ »

wkat4242 wrote: post #98
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…

The problem with internal CAs is also that it's really hard to add them on some OSes now. Especially on android since version 7 IIRC, you can no longer get certs into the system store, and every app is free to ignore the user store (I think it was even the default to ignore it). So a lot of apps will not work with it.

Speculating a bit out of my depth here, but I'm under the impression that most of those sometimes-configurable OS-level CA lists are treated as "trust anything consistent with this data", as opposed to "only trust this CA record for these specific domain-patterns because that's the narrow purpose I chose to install it for."

So there are a bunch of cases where we only want the second (simpler, lower-risk) case, but we have to incur all the annoyance and risk and locked-down-ness of the first use-case.

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

#120

Post by seb1204 »

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…

https://letsencrypt.org/ does not work?
Post reply on HN