Can we get .local or .l added for private-use applications too?
Please also reserve .lan which is what I now prefer to use since .local got stolen from private networks.
.INTERNAL is now reserved for private-use applications
221–230 of 290 posts
Re: .INTERNAL is now reserved for private-use applications
#222My 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.
My frustration is because using a private CA is more difficult than it should be.
You can't just add the CA to system trust stores on each device, because some applications, notably browsers and java, use their own trust stores, you have to add it to.
You also can't scope the CA to just .internal, which means in a BYOD environment, you have to require your employees to trust you not to sign certs for other domains.
And then there is running the CA itself. Which is more difficult than using let's encrypt.
Re: .INTERNAL is now reserved for private-use applications
#223Earlier quoted context omitted.
>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 i…
Wasn't aware of dnsmasq/pihole, I have a BIND9 configured to do it on my network and yeah its much nicer. I've seen people get bit by this all the time in college and still even now join projects with like weird hosts file usage. Instead of having 3 different systems for apple/ms/linux name resolution that don't interop the problem is better fixed higher up.
Re: .INTERNAL is now reserved for private-use applications
#224Earlier quoted context omitted.
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)
Cert pinning often annoyingly works against both - software devs are a third party to both the organizational users and their IT dept overlords.
Trusted computing is similar, too. It's a huge win for the user in terms of security, as long as the user owns the master key and can upload their own signatures. If not, then it suddenly becomes a very powerful form of control.
The more fundamental issue is the distinction between "user" and "owner" of a computer - or its component, or a piece of software - as they're often not the same people. Security technologies assert and enforce control of the owner; whether that ends up empowering or abusive depends on who the owners are, and why.
Re: .INTERNAL is now reserved for private-use applications
#225Earlier quoted context omitted.
Unlikely. Localhost can be a secure context because localhost traffic doesn't leave your local machine; .internal names have no guarantees about where they go (not inconceivable that some particularly "creative" admin might have .internal names that resolve to something on the public internet).
One can resolve "localhost" (even via an upstream resolver) to an arbitrary IP address. At least on my Linux system "localhost" only seems to be specially treated by systemd-resolved (with a cursory attempt I didn't succeed in getting it to use an upstream resolver for it). So it's not a rock-hard guarantee that traffic to localhost never leaves your system. It would be unconventional and uncommon for it to, though,…
No, you can't. Besides the /etc/hosts point mentioned in the sibling, localhost is often hard-coded to use 127.0.0.1 without doing an actual DNS lookup.
Re: .INTERNAL is now reserved for private-use applications
#226Earlier 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.
.com is not a full word either (company), or .org (organization), .net (internet), .gov (government), ...
.com is literally the opposite of a "reserved to never be used" word though?
Re: .INTERNAL is now reserved for private-use applications
#227Earlier 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, 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.
> 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.
Isn't certificate pinning on the way out? e.g. https://blog.cloudflare.com/why-certificate-pinning-is-outda...
Re: .INTERNAL is now reserved for private-use applications
#228Earlier quoted context omitted.
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
It was the latest nginx at the time. I actually found a rather obscure issue on Github that touches on this problem, for those who are curious:
https://github.com/kubernetes/ingress-nginx/issues/1681#issu...
> We discovered a related issue where we have multiple ssl-passthrough upstreams that only use different hostnames. [...] nginx-ingress does not inspect the connection after the initial handshake - no matter if the HOST changes.
That was 5-ish years ago though. I hope there are better ways than the cert hack now.
Re: .INTERNAL is now reserved for private-use applications
#229My 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…
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
If you're on a laptop or phone that switches between WiFi networks then you are potentially spilling session cookies and other data unencrypted onto other networks that also happen to resolve .internal. HTTPS encrypts connections, but it also authenticates servers. The later is important too.
Re: .INTERNAL is now reserved for private-use applications
#230Earlier 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.
Yes, but a convenient reserved TLD, formally declared never to be used by anyone and guaranteed to never resolve to anything by global DNS, is not accepted based on convenience alone. The ".dev" TLD is plenty useful as real domain. Plus, and this one's hard to believe, calling programming related work "dev" work is a surprisingly recent thing.