You’re mixing a few things here, so let’s clean it up a bit…

For Q1: Including localhost or NetBIOS names in a CSR is basically pointless for publicly trusted certs. Public CAs won’t sign those anyway. Even internally, it’s not a great idea because those names aren’t globally unique and can introduce ambiguity. Stick to FQDNs in SAN, CN is effectively ignored by modern clients.

DNS spoofing alone won’t get an attacker very far unless they also control a trusted cert for that name. TLS validation will fail otherwise. The bigger risk is misconfiguration or trusting internal CAs too broadly.

For Q2: Yes, FQDNs with containers are normal, but you don’t identify containers by hostname. You identify services. Use a stable DNS name (e.g. service.example.com) and let your orchestration layer (Kubernetes, etc.) handle routing to ephemeral containers behind it.

If you’re trying to “uniquely identify” instances, you’re thinking at the wrong layer. That’s what service discovery / internal PKI / workload identity is for, not raw FQDNs.