Does this mean .svc.cluster.local for Kubernetes should migrate to .svc.cluster.internal?
.INTERNAL is now reserved for private-use applications
211–220 of 290 posts
Re: .INTERNAL is now reserved for private-use applications
#212Are 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…
>Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com?
These local TLDs should IMO be used on all home routers, it fixes a lot of problems.
If you've ever plugged in e.g. a raspberry pi and been unable to "ping pi" it it's because there is no DNS mapping to it. There are cludges that Windows, Linux, and Macs use to get around this fact, but they only work in their own ecosystem, so you often can't see macs from e.g. windows, it's a total mess that leads confusing resolution behaviour, you end up having to look in the router page or hardcode the IP to reach a device which is just awful.
Home routers can simply assign pi into e.g. pi.home when doing dhcp. Then you can "ping pi" on all systems. It fixes everything- for that reason alone these reserved TLDs are, imo, useful. Unfortunately I've never seen a router do this, but here's hoping.
Also, p. sure I grew up playing wc3 w you?
Re: .INTERNAL is now reserved for private-use applications
#213Earlier quoted context omitted.
> 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 That's because the purpose of certificate pinning is to protect software from the user. Letting you supply your own certificates would defeat the purpose of having them.
Certificate pinning and restricting adding custom certificates to your OS except if you're using MDM are two completely unrelated things. Overriding system trust doesn't affect certificate pinning and certificate pinning is no longer recommended anyway.
They are certainly different things, but they're not unrelated. The inability of the user to change the system trust store is part of why certificate pinning is no longer (broadly) recommended.
Re: .INTERNAL is now reserved for private-use applications
#214Earlier quoted context omitted.
No. The concept of a DMZ died decades ago. You could still be MITM within your company intranet. Any system designed these days should follow zero-trust principles.
Sure, but people still need to test things, and HTTPS greatly complicates things. Browsers' refusal to make it poasible to run anything unencrypted when you know what you're doing is extremely annoying, and has caused significant losses of productivity throughout the industry. If they're so worried about users getting duped to activate the insecure mode, they could at least make it a compiler option and provide an en…
Indeed. Nothing enrages me more as a user when my browser refuses to load a page and doesn't give me any way to override it.
Whose computer is this? I guess the machine I purchased doesn't belong to me, but instead belongs to the developer of the browser, who has absolutely no idea what I'm trying to do, what my background is and qualifications and what my needs are? It seems absurd to give that person the ultimate say over me on my system, especially if they're going to give me some BS about protecting me from myself for my own good or something like that. Yet, that is clearly the direction things are headed.
Re: .INTERNAL is now reserved for private-use applications
#215Earlier quoted context omitted.
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.
A fun tale about wildcard certificates for internal subdomains:
The browser will gladly reuse an http2 connection with a resolved IP address. If you happen to have many subdomains pointing to a single ingress / reverse proxy that returns the same certificate for different Host headers, you can very well end up in a situation where the traffic will get messed up between services. To add to that - debugging that stuff becomes kind of wild, as it will keep reusing connections between browser windows (and maybe even different Chromium browsers)
I might be messing up technical details, as it's been a long time since I've debugged some grpc Kubernetes mess. All I wanted to say is, that having an exact certificate instead of a wildcard is also a good way to ensure your traffic goes to the correct place internally.
Re: .INTERNAL is now reserved for private-use applications
#216Earlier quoted context omitted.
Hoping datacenter to datacenter links are secure is how the NSA popped Google. Turn on crypto, don’t be lazy
Pretty sure state-level actors sniffing datacenter traffic is literally the very last of your security issues. This kind of theater actively harms your organization's security, not helps it. Do people not do risk analysis anymore?
It’s not theatre, it’s real security. And state level actors are absolutely not the only one capable of man in the middle attacks.
You have:
- employees at ISPs
- employees at the hosting company
- accidental network misconfigurations
- one of your own compromised machines now part of a ransomware group
- the port you thought was “just for internal” that a dev now opens for some quick testing from a dev box
Putting anything in open comms is one of the dumbest things you can do as an engineer. Do your job and clean that shit up.
It’s funny you mention risk analysis, plaintext traffic is one of the easiest things to compromise.
Re: .INTERNAL is now reserved for private-use applications
#217Earlier quoted context omitted.
Just use wildcard certs and internal subdomains remain internal information.
A fun tale about wildcard certificates for internal subdomains: The browser will gladly reuse an http2 connection with a resolved IP address. If you happen to have many subdomains pointing to a single ingress / reverse proxy that returns the same certificate for different Host headers, you can very well end up in a situation where the traffic will get messed up between services. To add to that - debugging that stuff…
Sounds like you need to get better reverse proxies...? Making your site traffic RELY on the fact that you're using different certificates for different hosts sounds fragile as hell and it's just setting yourself up for even more pain in the future
Re: .INTERNAL is now reserved for private-use applications
#218Earlier quoted context omitted.
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.
What do you see as the intended reasons with no other solutions?
Re: .INTERNAL is now reserved for private-use applications
#219Are 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…
>Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com? These local TLDs should IMO be used on all home routers, it fixes a lot of problems. If you've ever plugged in e.g. a raspberry pi and been unable to "ping pi" it it's because there is no DNS mapping to it. There are cludges that Windows, Linux, and Macs use to get around this fact, but the…
> Home routers can simply assign pi into e.g. pi.home when doing dhcp. Then you can "ping pi" on all systems. It fixes everything- for that reason alone these reserved TLDs are, imo, useful. Unfortunately I've never seen a router do this, but here's hoping.
dnsmasq has this feature. I think it’s commonly available in alternative router firmware.
On my home network, I set up https://pi-hole.net/ for ad blocking, and it uses dnsmasq too. So as my network’s DHCP + DNS server, it automatically adds dns entries for dhcp leases that it hands out.
There are undoubtably other options, but these are the two I’ve worked with.