DNS interno

Las redes de nube privada virtual en Google Cloud Platform (GCP) tienen un servicio DNS interno que permite que las instancias de la misma red accedan unas a otras mediante nombres DNS internos. Los registros A internos de instancias de máquina virtual (VM) se crean en una zona DNS para .internal. Los registros PTR para instancias de VM se crean en las zonas inversas correspondientes. A medida que administras tus instancias, GCP crea, actualiza y quita de forma automática estos registros DNS.

Por ejemplo, cuando borras una instancia, GCP quita de forma automática los registros A y PTR asociados con su nombre DNS .internal. Si luego creas una instancia con el mismo nombre, GCP crea un registro para el reemplazo.

Acerca de DNS interno

Los nombres DNS internos tienen las especificaciones siguientes:

  • El nombre DNS interno de una instancia de VM solo se resuelve a su dirección IP interna principal. Los nombres DNS internos no se pueden usar para conectarse a las direcciones IP externas de una instancia.

  • Los nombres DNS internos no se pueden configurar para resolverse en IP de alias secundarias.

  • Solo se pueden resolver los nombres DNS internos desde otras VM que estén en el mismo proyecto y usen la misma red de VPC o heredada. No puedes usar DNS interno para contactar instancias que se encuentren en otras redes, incluso si están en el mismo proyecto.

Registros PTR y DNS interno

El servicio de DNS interno de GCP crea de forma automática registros PTR para VM en las siguientes zonas inversas:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., … hasta 31.172.in-addr.arpa.

DNS interno y Cloud DNS

El DNS interno y Cloud DNS son ofertas diferentes. Los nombres DNS internos son los que GCP crea de forma automática. Si necesitas crear nombres DNS personalizados para tus instancias de VM, puedes usar una zona privada de Cloud DNS.

Para obtener información sobre cómo crear registros PTR personalizados que anulen los nombres PTR de DNS interno creados de forma automática, consulta Usa registros PTR en zonas privadas.

Nombres de host personalizados

Puedes especificar un nombre de host personalizado para una VM cuando la creas. Los nombres de host personalizados asignados de esta manera no se resuelven mediante DNS interno. Con los nombres de host personalizados, aún es necesario crear un registro DNS correspondiente en la zona adecuada (por ejemplo, mediante Cloud DNS). Consulta la página sobre cómo crear una instancia de VM con un nombre de host personalizado para obtener más información.

Tipos de nombres DNS internos

GCP tiene dos tipos de nombres DNS internos. El tipo de DNS interno predeterminado se establece en función de cuándo habilitaste la API de Compute Engine.

Tipo de DNS interno Nombre de dominio cualificado completo (FQDN) Tipo predeterminado del proyecto
DNS zonal [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal Valor predeterminado para todas las organizaciones o proyectos independientes que habilitaron la API de Compute Engine después del 6 de septiembre de 2018.
DNS global (para todo el proyecto) [INSTANCE_NAME].c.[PROJECT_ID].internal Valor predeterminado para todas las organizaciones o proyectos independientes que habilitaron la API de Compute Engine antes del 6 de septiembre de 2018.

en la que:

  • [INSTANCE_NAME] es el nombre de la instancia.
  • [ZONE] es la zona en la que se encuentra la instancia.
  • [PROJECT_ID] es el proyecto al que pertenece la instancia.

Para obtener información sobre cómo controlar qué tipo de nombre de DNS interno se usa a nivel de proyecto o instancia, consulta Configura nombres DNS para tu proyecto o instancias.

Nombres DNS internos y VPC compartida

Puedes usar un nombre DNS interno para hacer referencia a la dirección IP interna de una instancia, incluso cuando esa dirección IP se encuentra en una red de VPC compartida en un proyecto host. Con VPC compartida, la parte de ID de proyecto del nombre DNS interno zonal o global (para todo el proyecto) es el ID del proyecto de servicio.

Determina el nombre DNS interno para una instancia

Usa el procedimiento siguiente para leer el nombre DNS interno asignado a una instancia. La fuente de verdad de un nombre DNS interno es su servidor de metadatos.

  1. Conéctate a la instancia.
  2. Consulta el nombre de host en los metadatos de la instancia:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \
    -H "Metadata-Flavor: Google"
    

El formato del nombre de host indica el tipo de nombre DNS interno que usa la VM.

Accede a VM mediante DNS interno

El servidor de metadatos también es el agente de resolución del servidor de nombres para las consultas de DNS que emite la VM. El servidor de metadatos resuelve todas las consultas de DNS a nombres DNS internos y externos. Para consultas de DNS externo, el servidor de metadatos pasa las solicitudes a los servidores de nombres públicos de Google.

En el siguiente ejemplo, se usa ping para comunicarse con una instancia que usa DNS zonal. Este método funciona siempre y cuando crees una regla de firewall que permita el tráfico de ICMP entrante a la instancia.

$ ping [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal -c 1

PING [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal (10.240.0.17) 56(84) bytes of data.
64 bytes from [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal (10.240.0.17): icmp_seq=1 ttl=64 time=0.136 ms

en la que:

  • [INSTANCE_NAME] es el nombre de la instancia.
  • [ZONE] es la zona donde se encuentra la instancia.
  • [PROJECT_ID] es el proyecto al que pertenece la instancia.

DNS interno y resolv.conf

De forma predeterminada, la mayoría de las distribuciones de Linux guardan información de DHCP en resolv.conf. Las instancias de Compute Engine están configuradas para renovar las asignaciones de tiempo de DHCP cada 24 horas. En las instancias habilitadas para DNS zonal, la asignación de tiempo de DHCP caduca cada una hora. La renovación de DHCP reemplaza este archivo y deshace los cambios que realizaste. Las instancias que usan DNS zonal tienen entradas zonales y globales en el archivo resolv.conf.

DNS zonal

Archivo zonal resolv.conf de muestra:

# Local domain name. Computed from your project name.
domain [ZONE].c.[PROJECT_ID].internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
search [ZONE].c.[PROJECT_ID].internal. c.[PROJECT_ID].internal. google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254

en el que:

  • [ZONE] es la zona en la que se encuentra la instancia.
  • [PROJECT_ID] es el proyecto al que pertenece la instancia.

Archivo zonal dhcp.lease de muestra:

lease {
  # What interface we are using for the network
  interface "eth0";
  fixed-address 10.128.0.9;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  # Lease timeout, older VM instances will have this value set to infinite.
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 169.254.169.254;
  option dhcp-server-identifier 169.254.169.254;
  option interface-mtu 1460;
  # Search path options that are copied into the resolv.conf
  option domain-search "[ZONE].c.[PROJECT_ID].internal.", "c.[PROJECT_ID].internal.", "google.internal.";
  option ntp-servers 169.254.169.254;
  option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
  option host-name "[INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal";
  option domain-name "[ZONE].c.[PROJECT_ID].internal";
  renew 4 2017/11/16 02:15:52;
  rebind 4 2017/11/16 02:43:59;
  expire 4 2017/11/16 02:51:29;
}

en el que:

  • [INSTANCE_NAME] es el nombre de la instancia.
  • [ZONE] es la zona en la que se encuentra la instancia.
  • [PROJECT_ID] es el proyecto al que pertenece la instancia.

DNS global

Archivo global resolv.conf de muestra:

# Local domain name. Computed from your project name.
domain c.[PROJECT_ID].internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
search c.[PROJECT_ID].internal google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254

en el que [PROJECT_ID] es el proyecto al que pertenece la instancia.

Archivo global dhcp.lease de muestra:

lease {
  # What interface we are using for the network
  interface "eth0";
  fixed-address 10.128.0.8;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  # Lease timeout, older VM instances will have this value set to infinite.
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 169.254.169.254;
  option dhcp-server-identifier 169.254.169.254;
  option interface-mtu 1460;
  # Search path options that are copied into the resolv.conf
  option domain-search "c.[PROJECT_ID].internal.", "google.internal.";
  option ntp-servers 169.254.169.254;
  option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
  option host-name "[INSTANCE_NAME].c.[PROJECT_ID].internal";
  option domain-name "c.[PROJECT_ID].internal";
  renew 4 2017/11/16 12:07:00;
  rebind 4 2017/11/16 22:44:53;
  expire 5 2017/11/17 01:44:53;
}

en el que:

  • [INSTANCE_NAME] es el nombre de la instancia.
  • [PROJECT_ID] es el proyecto al que pertenece la instancia.

Estos archivos tienen las restricciones siguientes:

  • La ruta de búsqueda solo puede manejar 6 registros y Compute Engine proporciona 3 de estos registros. Si agregas entradas a la ruta de búsqueda de modo que el número total de entradas sea mayor que 6, tu SO no aplicará las reglas de búsqueda después de la 6.ª entrada. Esto puede hacer que se detenga la funcionalidad de Compute Engine, como el acceso a instancias a través de sus nombres de instancia.
  • La edición manual de resolv.conf hará que se revierta al DHCP predeterminado cada vez que caduque la asignación de tiempo de DHCP de 24 horas en tu instancia. En las instancias que usan DNS zonal, la asignación de tiempo de DHCP caduca cada una hora. Para realizar modificaciones estáticas en el archivo resolv.conf, varias distribuciones de Linux permiten que los elementos se adjunten antes o después a la política de DHCP.

Debian 9

Archivo /etc/dhcp/dhclient.conf de muestra:

# Configuration file for /sbin/dhclient.
#
...
append domain-search "mydomain.com";
prepend domain-name-servers 172.16.1.1;

en el que mydomain.com es el nuevo dominio de búsqueda y 172.16.1.1 es la IP de tu servidor DNS.

Nombres DNS zonales

Los nombres DNS zonales incluyen el nombre de tu instancia, la zona en la que se encuentra y el proyecto al que pertenece. Los nombres DNS globales no incluyen la zona en la que se encuentra la instancia. Los nombres DNS zonales en una ubicación funcionan de forma independiente de otras ubicaciones, lo que te permite compilar apps de región múltiple más tolerantes a errores con mejores características de disponibilidad.

Los proyectos y organizaciones existentes aún pueden usar nombres DNS globales, pero se recomienda que migren a nombres DNS zonales.

Configura nombres DNS para tu proyecto o instancias

Habilita las rutas de búsqueda de DNS zonal y global en tus instancias mediante la configuración de la variable VmDnsSetting en los metadatos de proyecto o de instancia. Si configuras la variable VmDnsSetting en metadatos para una instancia específica, se anulará cualquier variable VmDnsSetting heredada de los metadatos del proyecto de esa instancia.

La variable VmDnsSetting admite las siguientes configuraciones:

  • Configura VmDnsSetting=ZonalOnly para que solo se pueda acceder a tus instancias mediante sus nombres DNS zonales. Las instancias aún conservarán las rutas de búsqueda zonal y global, pero sus nombres DNS globales ya no funcionarán. Otras instancias solo pueden acceder a instancias con esta configuración mediante sus nombres DNS zonales y no mediante sus rutas de búsqueda o nombres DNS globales. Esta es la opción preferida siempre que tus apps la admitan. Esta es la configuración predeterminada para instancias en proyectos independientes y proyectos creados en una organización que habilitó la API de Compute Engine después del 6 de septiembre de 2018. Ten en cuenta que, si un proyecto se migra a una organización, su nombre DNS predeterminado no cambiará.
  • Configura VmDnsSetting=ZonalPreferred para habilitar las rutas de búsqueda de DNS zonal y mantener el nombre DNS global. Las instancias con esta configuración pueden acceder unas a otras mediante nombres DNS zonales o globales, y aún pueden acceder a instancias configuradas solo para nombres DNS globales.
  • Configura VmDnsSetting=GlobalOnly para que las instancias solo usen nombres globales como nombres de dominio y entradas de ruta de búsqueda. Usa este valor a fin de excluir instancias de una configuración DNS zonal para todo el proyecto o con el fin de restablecer tus instancias de forma que solo usen nombres DNS globales. Esta es la configuración predeterminada para instancias en proyectos independientes y proyectos creados en una organización que habilitó la API de Compute Engine antes del 6 de septiembre de 2018. Ten en cuenta que, si un proyecto se migra a una organización, su nombre DNS predeterminado no cambiará.

Consulta Establece metadatos personalizados para aprender a establecer valores de metadatos de instancia o metadatos de proyecto.

Después de configurar la variable VmDnsSetting para una instancia, actualiza la asignación de DHCP en la instancia. Puedes actualizar la asignación de tiempo si reinicias la instancia, si esperas que la asignación de tiempo caduque o si ejecutas uno de los comandos siguientes:

  • Instancias de Linux: sudo dhclient -v -r
  • Instancias de Windows Server: ipconfig /renew

Migra aplicaciones existentes a nombres DNS zonales

Aunque tus proyectos existentes pueden continuar con el uso de nombres DNS globales, se recomienda que migres tus instancias y apps existentes para que usen nombres DNS zonales y obtener los beneficios del sistema de DNS zonal. En general, puedes usar el proceso de migración siguiente:

  1. Verifica tus apps y actualízalas para resolver problemas de compatibilidad con la configuración zonal exclusiva:
    • Para las apps que acceden a instancias mediante su nombre o nombres de dominio globales calificados por completo, los nombres de instancia y los nombres de instancia global no siempre se resolverán en un entorno zonal exclusivo. Se recomienda actualizar estos nombres para usar nombres de dominio zonales calificados por completo.
    • Para las apps que suponen un formato específico de nombre de dominio global calificado por completo, suponer un formato de nombre de dominio, por lo general, representa un problema fundamental en el diseño de la app. Google recomienda que diseñes tus apps para que funcionen sin importar el formato del nombre de dominio.
    • Para las apps que no esperan cambios en el nombre de dominio, algunas podrían requerir un reinicio completo para recoger los nombres nuevos. Si es posible, actualiza tus apps para que identifiquen y manejen los cambios en el nombre de dominio de tu instancia.
  2. Configura las instancias en la red de VPC interna para que usen la configuración VmDnsSetting=ZonalPreferred, que usa los nombres DNS globales y zonales. Esta fase de transición permite que las instancias continúen con el uso de nombres globales hasta que tus apps estén listas para usar solo nombres zonales:
    1. Habilita VmDnsSetting=ZonalPreferred en una instancia mediante la configuración de ese valor en los metadatos personalizados.
    2. Actualiza la asignación de tiempo de DHCP en esa instancia para que comience a usar nombres DNS zonales:
      • Instancias de Linux: sudo dhclient -v -r
      • Instancias de Windows Server: ipconfig /renew
    3. Prueba las apps en esa instancia para asegurarte de que funcionen como se espera. Es posible que algunas apps no esperen cambios en el nombre de dominio y pueden requerir un reinicio completo para recoger los nombres nuevos.
    4. Repite este proceso para habilitar VmDnsSetting=ZonalPreferred y actualiza la asignación de tiempo de DHCP en las instancias restantes de tu red de VPC hasta que todas funcionen como se espera y usen solo los nombres DNS zonales. De manera alternativa, puedes establecer VmDnsSetting=ZonalPreferred en los metadatos del proyecto a fin de configurar todas las instancias del proyecto para que usen nombres DNS zonales.
  3. Una vez que tus apps se ejecuten de forma correcta solo con nombres de dominio zonales con la configuración VmDnsSetting=ZonalPreferred, puedes inhabilitar los nombres globales en esa red de VPC. Configura las instancias en tu red de nube privada virtual interna para que usen la configuración VmDnsSetting=ZonalOnly, que usa solo los nombres DNS zonales:
    1. Habilita VmDnsSetting=ZonalOnly en una instancia mediante la configuración de ese valor en los metadatos personalizados.
    2. Actualiza la asignación de tiempo de DHCP en esa instancia para que comience a usar nombres DNS zonales:
      • Instancias de Linux: sudo dhclient -v -r
      • Instancias de Windows Server: ipconfig /renew
    3. Prueba las apps en esa instancia para asegurarte de que funcionen como se espera.
    4. Repite este proceso para habilitar VmDnsSetting=ZonalOnly y actualiza la asignación de tiempo de DHCP en las instancias restantes de tu red de VPC hasta que todas funcionen como se espera y usen solo los nombres DNS zonales.
  4. Repite este proceso en cada una de tus redes de nube privada virtual hasta que todas las instancias de tu proyecto usen la configuración VmDnsSetting=ZonalOnly. Puedes establecer VmDnsSetting=ZonalOnly en los metadatos a nivel de proyecto para que se aplique de forma automática a cualquier instancia que crees en ese proyecto.

Inhabilita el DNS zonal en tu proyecto o instancias

Para inhabilitar el DNS zonal en una instancia específica, configura VmDnsSetting=GlobalOnly en los metadatos de esa instancia. Para inhabilitar el DNS zonal en un proyecto, configura VmDnsSetting=GlobalOnly en los metadatos del proyecto y asegúrate de que ninguna de tus instancias esté configurada de forma individual con el valor VmDnsSetting. Consulta Establece metadatos personalizados para aprender a establecer valores de metadatos de instancia o metadatos de proyecto.

Si necesitas forzar la actualización inmediata de la asignación de tiempo de DHCP, puedes usar uno de los comandos siguientes:

  • Container-optimized OS (Google Kubernetes Engine): sudo systemctl restart systemd-networkd
  • Instancias de entorno flexible de Debian/App Engine: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Ubuntu 15.04 y posterior: sudo dhclient -r -v ens4 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v ens4
  • Ubuntu anterior a la versión 15.04: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Windows: ipconfig /renew

Algunos sistemas operativos no cambian por completo sus configuraciones de DNS, incluso después de que se renueve la asignación de tiempo de DHCP. En esos casos, reinicia la red de la instancia de VM para forzar el cambio de configuración de DNS:

  • Ubuntu: sudo ifdown --exclude=lo -a && sudo ifup --exclude=lo -a
  • CentOS: sudo /etc/init.d/network restart
  • CoreOS: sudo systemctl restart systemd-networkd
  • Container-optimized OS: sudo systemctl restart systemd-networkd

Si ejecutas tu app en contenedores, en Google Kubernetes Engine o en el entorno flexible de App Engine, es posible que la configuración de DNS de tu contenedor no se actualice de forma automática hasta que reinicies los contenedores. Para inhabilitar el DNS zonal en estas apps de contenedor, debes configurar VmDnsSetting=GlobalOnly en tus instancias y proyectos, y reiniciar los contenedores para que su configuración de DNS vuelva al estado original.

Próximos pasos

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Compute Engine