DNS interno


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

Por ejemplo, cuando borras una instancia, Google Cloud quita de forma automática los registros A y PTR asociados con su nombre de DNS .internal. Si luego creas una instancia con el mismo nombre, Google Cloud 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.

  • Los nombres DNS internos solo se pueden resolver desde las VM que estén en la misma red. Estas VM pueden estar en el mismo proyecto que la red o en proyectos de servicio que usan la misma red de VPC compartida. Para resolver los nombres DNS de las VM en proyectos de servicio, debes usar los FQDN de las VM. No puedes usar DNS interno para contactar a las VM que están en una red diferente.

Tipos de nombres DNS internos

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

En general, Google recomienda enfáticamente usar DNS zonal, ya que ofrece garantías de confiabilidad más altas mediante el aislamiento de las fallas en el registro DNS en zonas individuales.

Tipo de DNS interno Nombre de dominio cualificado completo (FQDN) Tipo predeterminado del proyecto Notas
DNS zonal VM_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. Los nombres de las instancias de VM deben ser únicos dentro de la zona, pero pueden repetirse en varias zonas. Por ejemplo, puedes tener varias instancias llamadas instance-1, siempre que las instancias se encuentren en zonas distintas.
DNS global (para todo el proyecto) VM_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. Los nombres de las instancias de VM deben ser únicos en todo el proyecto. No puedes repetir los nombres de las instancias.

Reemplaza lo siguiente:

  • VM_NAME: es el nombre de la VM. En el DNS zonal, este valor debe ser único dentro de la zona, pero se puede repetir entre zonas. Para el DNS global, el nombre de la instancia debe ser único en todo el proyecto.
  • ZONE: 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.

Registros PTR y DNS interno

El servicio de DNS interno de Google Cloud 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.

Registros personalizados con Cloud DNS

Puedes usar una zona privada de Cloud DNS a fin de crear entradas DNS personalizadas para tus instancias de VM. Puedes configurar registros PTR que te permiten anular la URL de VM de DNS interna predeterminada con la URL personalizada que proporciones.

Para crear registros PTR personalizados que anulen los nombres PTR de DNS internos que se crearon de forma automática, consulta Registros PTR de direcciones RFC 1918 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). Para obtener más información, consulta Crea una instancia de VM con un nombre de host personalizado.

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 del ID del proyecto del nombre DNS interno zonal o global (para todo el proyecto) es el ID del proyecto de servicio.

Determina el nombre de DNS interno para una instancia de 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. Conectarte a la instancia de VM.
  2. Consulta los metadatos hostname:

    VM de Linux

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

    VM de Windows

    Invoke-RestMethod `
      -Headers @{"Metadata-Flavor" = "Google"} `
      -Uri "http://metadata.google.internal/computeMetadata/v1/instance/hostname"
    

El servidor de metadatos muestra el nombre de host de la VM en uno de los siguientes formatos y, luego, el tipo de nombre DNS interno que usa la VM:

  • DNS zonal: VM_NAME.ZONE.c.PROJECT_ID.internal
  • DNS Global: VM_NAME.c.PROJECT_ID.internal

En el resultado verás lo siguiente:

  • VM_NAME: el nombre de la instancia de VM
  • ZONE: Es la zona en la que se encuentra la instancia.
  • PROJECT_ID es el proyecto al que pertenece la instancia.

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 VM_NAME.ZONE.c.PROJECT_ID.internal -c 1

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

Reemplaza lo siguiente:

  • VM_NAME: el nombre de la instancia de VM
  • 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.

En las distribuciones de Linux que almacenan información de DHCP en systemd.resolved.conf, puedes ver las entradas de DNS zonales y globales en el archivo /etc/systemd/resolved.conf.

Nota: Las redes de VPC tienen una unidad de transmisión máxima (MTU) predeterminada de 1460 bytes. Sin embargo, la MTU de la red se puede establecer en 1500 bytes. Consulta Unidad de transmisión máxima para obtener información general sobre las MTU de red.

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

Reemplaza lo siguiente:

  • ZONE: 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 "VM_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;
}

Reemplaza lo siguiente:

  • VM_NAME: El nombre de la VM
  • ZONE: La zona en la que se encuentra la VM.
  • PROJECT_ID: el proyecto al que pertenece la VM

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

Reemplaza PROJECT_ID por 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 "VM_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;
}

Reemplaza lo siguiente:

  • VM_NAME: El nombre de la VM
  • PROJECT_ID: el proyecto al que pertenece la VM

Estos archivos tienen las siguientes restricciones:

  • 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 aplica 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 este ejemplo, 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 VM, 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 VM. 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 el DNS zonal y el DNS global para tus instancias mediante la configuración de la variable VmDnsSetting en los metadatos del proyecto o de la 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:

  • Recomendado: 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 y más confiable, 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.
  • 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. Esta opción se puede usar como un paso intermedio para probar nombres DNS zonales.
  • Configura VmDnsSetting=GlobalDefault para que las instancias registren nombres DNS globales y zonales, pero solo usen nombres globales como nombres de dominio predeterminados y entradas de ruta de búsqueda. 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 migrar un proyecto a una organización diferente no cambia el nombre DNS predeterminado del proyecto.

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

Después de actualizar la asignación de tiempo de DHCP, verifica si tu VM está habilitada para el DNS zonal.

Migra aplicaciones existentes a nombres DNS zonales

Se reemplazó el DNS global por el DNS zonal. Si tus proyectos existentes todavía usan DNS global, Google recomienda que migres las instancias y apps existentes para que usen nombres DNS zonales. Los nombres DNS zonales mitigan el riesgo de interrupciones interregionales.

En general, puedes usar el siguiente proceso de migración:

  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. Una vez que tus apps se ejecuten de forma correcta solo con nombres de dominio zonales, 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.
  3. 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.

Para forzar el cambio de configuración de DNS, reinicia la red de la instancia de VM:

  • Container-Optimized OS/Ubuntu: sudo systemctl restart systemd-networkd
  • CentOS/RHEL/Fedora CoreOS/Rocky Linux: sudo systemctl restart network
  • Debian: sudo systemctl restart networking
  • Windows: ipconfig /renew

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 se revierta al estado original.

¿Qué sigue?