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

201–210 of 290 posts

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

#201

Post by layer8 »

pas wrote: post #196
layer8 wrote: post #188

Earlier quoted context omitted.

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 tru…

You’re basically saying that .internal can cause frustration when it is used without good reason. Fair enough, but also not surprising. When it is used for the intended reasons though, then there’s just no other solution. It’s a trade-off between conflicting goals. “Simply do X instead” doesn’t remove the trade-off.

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

#202

Post by cobbal »

TeMPOraL wrote: post #178
okanat wrote: post #169

Earlier quoted context omitted.

Protect the software from the user? Why are you giving them the software then?

Most software is tools of control and exploitation, and remains in an adversarial relationship with its users. You give software to users to make them make money for you; you protect the software from users so they don't cut you out, or use software to do something you'd rather they don't do. Software that isn't like that is in a minority, and most of it is only used to build software that is like that.

It's interesting that cert pinning cuts both ways though. It can also be a tool to give users power against the IT department (typically indistinguishable from malware)

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

#203

Post by bruce511 »

Spooky23 wrote: post #127
bruce511 wrote: post #92

Earlier quoted context omitted.

The big problem with running unencrypted HTTP on a LAN is that it's terribly easy for (most) LANs to be compromised. Let's start with the obvious; wifi. If you're visiting a company and ask the receptionist for the wifi password you'll likely get it. Next are eternity ports. Sitting waiting in a meeting room, plug your laptop into the ethernet port and you're in. And of course it's not just hardware, any software run…

The big issue with encrypted HTTP on the local LAN is that you’re stuck running a certificate authority, ignoring TLS validation, or exposing parts of your network in the name of transparency. Running certificate authority is one of those a minute to learn, lifetime to master scenarios. You are often trading “people can sniff my network scenario” to a “compromise the CA someone setup 10 years ago that we don’t touch”…

I agree that setting up a self-signed CA is hard, and harder to keep going.

However DNS challenge allow for you to map an internal address to an IP number. The only real information that leaks is the subnet address of my LAN. And given the choice of that or unencrypted traffic I'll take that all day long.

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

#204

Post by bruce511 »

PokestarFan wrote: post #128
slimsag wrote: post #124

Earlier quoted context omitted.

Also, make sure your TLS certificates are hard-coded/pinned in your application binary. Just like the network, you really cannot trust what is happening on the user's system. This way you can ensure you as the developer have full control over your applications' network communication; by requiring client certificates issued by a CA you control, you can assert there is no MITM even if a sysadmin, user, or malware tries…

At some point you have to wonder if your app even matters that much.

The App probably not. The server maybe, the data probably.

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

#205

Post by 8organicbits »

pas wrote: post #196
layer8 wrote: post #188

Earlier quoted context omitted.

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 tru…

I'll add that anyone using VMs or containers will also run into trust issues too without extra configuration. I've seen lots of contractors resort to just ignoring certificate warnings instead of installing the corporate certs for each client they work with.

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

#206

Post by mrighele »

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 would expect ACME to use https://testing.acme.internal, and not just https://testing.internal, that would remove most of the incidental clashes (not malicious ones, of course).

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

#207

Post by dijit »

jhardy54 wrote: post #91
booi wrote: post #80

Earlier quoted context omitted.

And in on some platforms and configurations, impossible. Same with the .dev domain

.dev isn’t a TLD for internal use though, do you have the same problem when you use .test?

gonna go ahead and cast shade at Google because of how they handled that.

Their original application for .dev was written to "ensure its reserved use for internal projects - since it is a common internal TLD for development" - then once granted a few years later they started selling domains with it.

** WITH HSTS PRELOADING ** ensuring that all those internal dev sites they were aware of would break.

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

#208

Post by soneil »

jeroenhd wrote: post #16
tetris11 wrote: post #5

I need a dumbed down version of this.

Remember how tons of developers got surprised when Google got the .dev TLD, because they were using domains they didn't own to develop software? Well, now .internal has been reserved so developers and companies can safely use .internal domains without that happening to them.

.local being used for mDNS while Microsoft were using it in AD examples/documentation is another good example.

.internal is just admitting there's only so many times we can repeat the same mistake before we start to look silly.

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

#209

Post by soneil »

amelius wrote: post #199
cloudyporpoise wrote: post #197

Earlier quoted context omitted.

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"

It's a bit of both - you do have to pull out your wallet, but there's also an approval process. Just because you can buy a gTLD, doesn't mean you can buy .con

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

#210

Post by qwertox »

qmarchi wrote: post #125
Helmut10001 wrote: post #114

Earlier quoted context omitted.

Just use wildcard certs and internal subdomains remain internal information.

There's a larger risk that if someone breaches a system with a wildcard cert, then you can end up with them being able to impersonate _every_ part of your domain, not just the one application.

I issue a wildcard cert for *.something.example.com.

All subdomains which are meant for public consumption are at the first level, like www.example.com or blog.example.com, and the ones I use internally (or even privately accessible on the internet, like xmpp.something.example.com) are not up for discovery, as no public records exist.

Everything at *.something.example.com, if it is supposed to be privately accessible on the internet, is resolved by a custom DNS server which does not respond to `ANY`-requests and logs every request. You'd need to know which subdomains exist.

something.example.com has an `NS`-record entry with the domain name which points to the IP of that custom DNS server (ns.example.com).

The intranet also has a custom DNS server which then serves the IPs of the subdomains which are only meant for internal consumption.

Post reply on HN