Descripción general del DNS interno

Cuando creas instancias de máquinas virtuales (VMs) de Compute Engine, el DNS interno crea automáticamente un nombre de DNS para la VM. Este nombre de DNS facilita la comunicación interna de una VM a otra mediante la resolución de direcciones IP internas. Las redes de nube privada virtual en Google Cloud usan el servicio de DNS interno para permitir que las VMs de la misma red accedan unas a otras mediante nombres de DNS internos.

Google Cloud crea, actualiza y quita de forma automática los siguientes tipos de registros DNS a medida que administras tus VMs:

  • Los registros de dirección de DNS, o registros A, se crean para las VMs en una zona del DNS de .internal.
  • Los registros PTR de las VMs, que se usan para la búsqueda de DNS inversa, se crean en las zonas inversas correspondientes.

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

Limitaciones

Los nombres DNS internos tienen las especificaciones siguientes:

  • El nombre DNS interno de una 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 VM.

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

Nombres de DNS internos zonales y globales

Google Cloud tiene dos tipos de nombres de DNS internos:

  • DNS zonal: Los nombres de las VM deben ser únicos dentro de cada zona, pero puedes volver a usar los nombres de las VM en todas las zonas. Por ejemplo, puedes tener varias VMs llamadas instance-1, siempre que las VMs estén en diferentes zonas.
  • DNS global: Los nombres de las VM deben ser únicos en cada proyecto. Con el DNS global, no puedes volver a usar los nombres de VM dentro del proyecto.

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. En el caso de una interrupción, el DNS global tiene los siguientes problemas:

  • El nombre de la VM debe ser único en todo el proyecto. Como resultado, no puedes crear VMs nuevas en ninguna región que experimente fallas del plano de control en las que tienes o tenías recursos de proyecto. Google Cloud no puede verificar los nombres de DNS del recurso existente en la región no disponible.
  • Algunas funciones de Compute Engine no están disponibles, como el ajuste de escala automático de los grupos de instancias administrados (MIG). Como resultado, las aplicaciones que usan el ajuste de escala automático para manejar con facilidad los aumentos de carga de trabajo no pueden escalar verticalmente.

El tipo de DNS interno predeterminado se establece cuando habilitas la API de Compute Engine.

  • El tipo de DNS interno predeterminado es DNS zonal.
  • Si tu organización o proyecto independiente habilitó la API de Compute Engine antes del 6 de septiembre de 2018, el tipo de DNS interno predeterminado se establece en DNS global.

En la siguiente tabla, se describen los nombres de dominio completamente calificados para los nombres de DNS internos.

Tipo de DNS interno Nombre de dominio completamente calificado (FQDN)
DNS zonal VM_NAME.ZONE.c.PROJECT_ID.internal
DNS global (para todo el proyecto) VM_NAME.c.PROJECT_ID.internal

Reemplaza lo siguiente:

  • VM_NAME: 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 VM debe ser único en todo el proyecto.
  • ZONE: La zona en la que se encuentra la instancia.
  • PROJECT_ID: el proyecto al que pertenece la VM

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.

Resolución de nombre del DNS

Las VMs reciben información de la resolución del DNS interno como parte de sus asignaciones de tiempo de DHCP. El método de resolución de DNS depende de la plataforma del sistema operativo:

  • Linux: De forma predeterminada, el servidor DNS de la VM (169.254.169.254:53) resuelve los nombres DNS internos.
  • Windows: de forma predeterminada, la puerta de enlace predeterminada de la subred resuelve los nombres DNS internos.

Zonas inversas para registros PTR

El servicio de DNS interno de Google Cloud crea de forma automática registros PTR para VMs 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.

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.

Personaliza nombres de DNS internos

Algunas organizaciones o aplicaciones pueden requerir nombres de DNS internos personalizados en lugar de los nombres de DNS internos predeterminados que creó Google Cloud.

Zonas privadas y registros personalizados con Cloud DNS

Puedes usar una zona privada de Cloud DNS a fin de crear entradas de DNS personalizadas para tus VMs. Puedes configurar registros PTR que te permiten anular la URL de DNS interna predeterminada para tu VM 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. Para obtener información sobre cómo crear registros PTR para VMs, consulta Crea un registro PTR para una instancia de VM.

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.

DNS interno y DHCP

Las VMs de Compute Engine están configuradas para renovar las asignaciones de tiempo de DHCP cada 24 horas. En las VMs habilitadas para DNS zonal, la asignación de tiempo de DHCP caduca cada una hora. Las VMs que usan DNS zonal tienen entradas zonales y globales en el archivo de configuración de DHCP.

De forma predeterminada, la mayoría de las distribuciones de Linux guardan información de DHCP en resolv.conf. La edición manual de resolv.conf hace que se revierta al DHCP predeterminado cada vez que caduque la asignación de tiempo de DHCP en tu VM. 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.

La forma en que modificas la política de DHCP o el archivo de configuración depende de la distribución de Linux que uses. Por ejemplo, Red Hat Enterprise Linux y Debian usan el archivo de configuración /etc/dhcp/dhcpd.conf. En CentOS, usa la utilidad de línea de comandos de Administrador de redes,nmcli .

Consulta la documentación de tu sistema operativo para obtener información sobre cómo establecer la configuración de redes DHCP y DNS personalizadas. Por ejemplo, en Red Hat Enterprise Linux para SAP con HA y Update Services 8.6, usa el siguiente vínculo: Configura de forma manual el archivo /etc/resolv.conf

Archivo resolv.conf de ejemplo

De forma predeterminada, la mayoría de las distribuciones de Linux guardan información de DHCP en resolv.conf. El servicio systemd-resolved también proporciona servicios de resolución para DNS. Para configurar este servicio, edita el archivo /etc/systemd/resolved.conf y otros archivos *.conf en el directorio /etc/systemd/resolved.conf.d/. En las distribuciones de Linux que almacenan información de DHCP en resolved.conf, puedes ver las entradas de DNS zonales y globales en el archivo /etc/systemd/resolved.conf.

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.a entrada. Esto puede hacer que se detengan las funciones de Compute Engine, como el acceso a las VMs mediante 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 VM. En las VMs 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.

Configuración de 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 VM.
  • PROJECT_ID: el proyecto al que pertenece la VM

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

Configuración de 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 VM.

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

Archivo dhclient.conf de ejemplo

Algunos sistemas operativos, como Debian 9, usan el archivo dhclient.conf en lugar del archivo resolv.conf.

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 dominio de búsqueda nuevo y 172.16.1.1 es la IP de tu servidor DNS.

¿Qué sigue?