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

281–290 of 290 posts

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

#281

Post by JackSlateur »

pid-1 wrote: post #49
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…

> leading Amazon's strategy for cloud-native AWS usage internally I've been on the other end of the business scale for the past decade, mostly working for SMBs like hedge funds. That made me a huge private DNS hater. So much trouble for so little security gain. Still, it seems common knowledge is to use private DNS for internal apps, AD and such, LAN hostnames and likes. I've been using public DNS exclusively everywh…

Exactly

And the larger the scale, to more benefits you get from avoiding internal-specific resolution.

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

#282

Post by lysace »

laz wrote: post #130
lysace wrote: post #88

Earlier quoted context omitted.

There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.

Exactly what an NSA puppet account would say! Don't believe the hype. Remember the smiley from "SSL added and removed here" https://blog.encrypt.me/2013/11/05/ssl-added-and-removed-her...

This "NSA puppet" is all for encrypting traffic between networks.

;-)

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

#284

Post by Arch-TK »

thaumasiotes wrote: post #277
Arch-TK wrote: post #275

Earlier quoted context omitted.

Android locking the system certificate store has nothing to do with preventing people from intercepting app traffic for the purpose of inspecting an application and everything to do with preventing people from accidentally installing a malicious certificate which allows part or all their traffic to be MITM-ed.

Those are literally the same thing.

No, there are legitimate reasons to install a certificate to intercept traffic as an owner of a device. But the same tools can be abused by malware and by malicious actors to intercept traffic. Its the same in a strictly technical sense but not the same in the intent sense. The intent is to prevent malicious abuse of the feature, not justified non-malicious use. It helps make it harder to intercept application traffic but this is not the intent of the restriction, merely an unintended consequence.

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

#285

Post by neop1x »

NewJazz wrote: post #253
mjevans wrote: post #221

Earlier quoted context omitted.

Please also reserve .lan which is what I now prefer to use since .local got stolen from private networks.

You can use .home.arpa. https://datatracker.ietf.org/doc/html/rfc8375

You can use a public subdomain like box.uuid.california.usa.mydns.org but we need something short like .l or .lan :) .home.arpa is terrible.

I have been using .l personally for a couple of years and it works fine except Chrome won't recognize it as a tld and would start a google search. Once it is visited a couple of times, it autocompletes it as a webpage so it's quite usable afterall.

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

#286

Post by Helmut10001 »

brewmarche wrote: post #279
Helmut10001 wrote: post #273

Earlier quoted context omitted.

This is also my thinking.. if someone compromises your VM that is responsible for retrieving wildcard certs from let's encrypt, then you're probably busted anyway. Such a machine would usually sit at the center of infrastructure, with limited need to be connected to from other machines.

Probably most people would deem the risk negligible, but it’s still worth to mention it, since you should evaluate for yourself. Regarding the central machine: the certificate must not only be generated or fetched (which as you said probably will happen “at the center”) but also deployed to the individual services. If you don’t use a central gateway terminating TLS early the certificate will live on many machines, no…

You are absolutely right. And deployment can be set up to open up additional vulnerabilities and holes. But there are also many ways to make the deployment quite robust (e.g. upload via push to a deploy server, distribute from there). ... and just by chance, I've written a small bash script that helps to distribute SSL certificates from a centrally managed "deploy" server 8) [1].

[1]: https://github.com/Sieboldianus/ssl_get

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

#287

Post by [deleted] »

neop1x wrote: post #285
NewJazz wrote: post #253

Earlier quoted context omitted.

You can use .home.arpa. https://datatracker.ietf.org/doc/html/rfc8375

You can use a public subdomain like box.uuid.california.usa.mydns.org but we need something short like .l or .lan :) .home.arpa is terrible. I have been using .l personally for a couple of years and it works fine except Chrome won't recognize it as a tld and would start a google search. Once it is visited a couple of times, it autocompletes it as a webpage so it's quite usable afterall.

[deleted]

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

#288

Post by NewJazz »

eddyg wrote: post #118
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...

They could be gTLDs in the far future, but ICANN is likely to hold off for a good long while. Better to use something that is actually reserved, though. You never know.

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

#289

Post by ghshephard »

fulafel wrote: post #240
kevincox wrote: post #170

Earlier quoted context omitted.

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 usually little reason to use reserved space vs internet addresses, unless you just want to relive the pain of NAT+IPv4. The exception is if you lack PI space and can't copy with potential renumbering.

I've deployed/managed over 25 million production elements in RFC4193 space. These elements ((mostly mesh networking nodes for utilities) ), by definition, should never route to the internet. (According to NERC CIP they shouldn't even route beyond the substation for distribution elements).

Non routability was a design feature.

I've been out of Enterprise IT for 15 years - but if I was going to do an IPv6 deployment today - I would strongly consider NAT6 prefix replacement - it offers 90% of the benefits of native IPv6 addresses, doesn't conflate "security" and "flexibility" (prefix replacement is just a straight 1:1 passthrough - globally routable) - and who want to go update all their router configs and DNS every time they change their upstream. Ugh.

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

#290

Post by nightpool »

ivankuz wrote: post #262
ploxiln wrote: post #242

Earlier quoted context omitted.

That's a misunderstanding in your use of this ingress-controller "ssl-passthrough" feature. > This feature is implemented by intercepting all traffic on the configured HTTPS port (default: 443) and handing it over to a local TCP proxy. This bypasses NGINX completely and introduces a non-negligible performance penalty. > SSL Passthrough leverages SNI and reads the virtual domain from the TLS negotiation So if you want…

Thank you very much for such a clear explanation of what's happening. Yeah, I sensed that it's not a limitation of the nginx per-se, as it was asked not to do ssl termination, hence of course it can't extract header from the scrambled bytes. As I needed it to do grpc through asp.net, it is a kestrel requirement to do ssl termination that forced me to use the ssl-passthrough, which probably comes from a whole differen…

> it is a kestrel requirement to do ssl termination

Couldn't you just pass it x-forwarded-proto like any other web server? or use a different self signed key between nginx and kestrel instead?

Post reply on HN