zlacker

>>fanf2+(OP)
> The Kubernetes DNS resolves A-B-C-D.N.pod.cluster.local to A.B.C.D, as long as A.B.C.D is a valid IP address and N is an existing namespace. Let’s be honest: I don’t know how this serves any purpose, but if you do, please let me know!

You can use that to

- test weird dns setups

- to issue proper TLS certificates (you can do that technically, but it's less known fact and some services like let's encrypt forbid that as their rule)

- to utilize single IP and same port for multiple services (so just a common host/server configuration on typical reverse proxy, optionally with SNI to be used with TLS on top.

>>szszrk+Kx2
I don’t think you can issue proper cert for a private IP. So using dns host name is the only option.

>>vbezhe+3B7
If you control an internal CA you can make certs for anything. I have one for my homelab, and even have a few certs issued for my homelab, which are not for domains i control as well as certs with IPs. The CA is who says you cant do those things, and yes its generally agreed upon for the public internet, certs shouldnt have IPs in them, but if you are operating internally theres nothing stopping you.