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.

>>CableN+zE7
> its generally agreed upon for the public internet, certs shouldnt have IPs in them

That's a bit of a stretch to say anyone agreed on not using IP based certs. Quite the contrary. It is present in RFC 5280 and SAN can contain an IP. It's just very rare to do that, but can be done and is done. Modern browsers and OSs accept it as well.

It's nice when you need to do some cert pinning to make sure there is not MITM eavesdropping, or for example on some onprem environments where you can't fully control workstations/DNS of you user endpoints, but still want to have your services behind certs that actually properly validate.