DNS interno

Las redes de nube privada virtual en 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 VM se crean en las zonas inversas correspondientes. A medida que administras tus instancias de VM, GCP crea, actualiza y quita de forma automática estos registros DNS.

Por ejemplo, si borras una VM, GCP quita de forma automática los registros A y PTR asociados con su nombre DNS .internal. Si creas una VM nueva con el mismo nombre, GCP crea un registro nuevo 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 VM, puedes usar una zona privada de Cloud DNS.

Si necesitas crear registros PTR personalizados que anulen los registros PTR de DNS interno creados de forma automática, consulta el uso de registros PTR en zonas privadas en la documentación de Cloud DNS.

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 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.

donde:

  • [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.

Puedes controlar qué tipo de nombre DNS interno se usa a nivel de proyecto o de instancia. Consulta la sección 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 VM, incluso cuando esa dirección IP se encuentra en una red de VPC compartida en un proyecto de 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 VM

Usa el procedimiento siguiente para leer el nombre DNS interno asignado a una VM. 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 utiliza 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

donde:

  • [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 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

Ejemplo de archivo zonal resolv.conf:

# 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

donde:

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

Ejemplo de archivo zonal dhcp.lease:

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;
}

donde:

  • [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 global

Ejemplo de archivo resolv.conf global:

# 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.

Ejemplo de archivo dhcp.lease global:

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;
}

donde:

  • [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

Ejemplo de archivo /etc/dhcp/dhclient.conf:

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

donde mydomain.com es el dominio de búsqueda nuevo 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 aplicaciones 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 o 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.

  • 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 aplicaciones 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 Configura 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 aplicaciones 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 aplicaciones y actualízalas para resolver problemas de compatibilidad con la configuración zonal exclusiva:
    • Para las aplicaciones 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 aplicaciones 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 aplicación. Google recomienda que diseñes tus aplicaciones para que funcionen sin importar el formato del nombre de dominio.
    • Para las aplicaciones 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 aplicaciones 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 utiliza 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 aplicaciones 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 aplicaciones en esa instancia para asegurarte de que funcionen como se espera. Es posible que algunas aplicaciones 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 aplicaciones 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 la red de VPC interna para que usen la configuración VmDnsSetting=ZonalOnly, que utiliza 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 aplicaciones 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 VPC 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 Configura 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 Debian o Google App Engine Flex: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Ubuntu 15.04 y superior: sudo dhclient -r -v ens4 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v ens4
  • Ubuntu anterior a 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 aplicación en contenedores, en 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 aplicaciones 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.

Pasos siguientes

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

Enviar comentarios sobre...

Documentación de Compute Engine