Las VM internas en la misma VPC deben acceder a myglobalapp.terramearth.com de forma privada (no pueden usar la IP externa global). El DNS público actualmente resuelve el nombre a la IP pública. Siguiendo las mejores prácticas de Google, ¿cómo se configura Cloud DNS para que los clientes internos lleguen a la aplicación a través de su IP privada?

La creación de una zona privada de Cloud DNS para myglobalapp.terramearth.com con un registro A que apunte a la IP interna de la aplicación, y vinculando esta zona a la VPC, es la solución correcta. Esto permite que las VMs dentro de la VPC resuelvan el nombre de dominio a la IP privada, mientras que las consultas externas siguen resolviendo a la IP pública, un patrón conocido como "split-horizon DNS". Las otras opciones son incorrectas: Crear un subdominio internal.terramearth.com requeriría que las aplicaciones cambien la forma en que acceden al servicio, lo cual no cumple el requisito de que accedan a myglobalapp.terramearth.com. Cloud DNS no ofrece una funcionalidad de "script de lógica de consulta" para detectar IPs de origen y devolver diferentes registros. Modificar el archivo hosts de cada cliente es una solución manual, no escalable y no es una buena práctica en entornos de nube. Además, promover la IP a estática y cambiar el registro público no resuelve el problema de acceso privado interno.