Descripción general del DNS interno

Cuando creas instancias de Compute Engine, el DNS interno crea automáticamente un nombre de DNS para la instancia. Este nombre de DNS facilita la comunicación interna de una instancia 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 instancias de procesamiento 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 instancias:

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

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

Limitaciones

  • Compute Engine crea registros A y PTR de nombres de DNS internos solo para la dirección IPv4 interna principal de la interfaz de red nic0 de una instancia. En consecuencia, el tipo de pila de la interfaz de red nic0 debe ser solo IPv4 o de pila doble. El DNS interno no admite interfaces de red solo IPv6 (versión preliminar).

  • Compute Engine no crea registros DNS internos para lo siguiente:

    • La dirección IPv4 interna principal de una interfaz de red diferente de nic0
    • Una dirección IPv4 externa de cualquier interfaz de red.
    • Una dirección IPv4 interna de un rango de alias de IP de cualquier interfaz de red
    • Un rango de direcciones IPv6 interno o externo de cualquier interfaz de red

  • Para resolver nombres de DNS internos, se requiere que la VM cliente y la VM asociada con el registro de DNS interno cumplan con los siguientes requisitos:

    • En la misma red de VPC
    • En el mismo proyecto (excepto en ciertas situaciones de VPC compartida).

    Para obtener más información sobre las situaciones de VPC compartida, consulta Nombres de DNS internos y VPC compartida.

Nombres de DNS internos zonales y globales

Google Cloud tiene dos tipos de nombres de DNS internos:

  • DNS zonal: Los nombres de las instancias deben ser únicos dentro de cada zona, pero puedes volver a usar los nombres de las instancias en todas las zonas. Por ejemplo, puedes tener varias instancias llamadas instance-1, siempre que estas se encuentren en zonas distintas.
  • DNS global: Los nombres de las instancias deben ser únicos en cada proyecto. Con el DNS global, no puedes volver a usar los nombres de las instancias 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 instancia debe ser único en todo el proyecto. Como resultado, no puedes crear instancias 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 INSTANCE_NAME.ZONE.c.PROJECT_ID.internal
DNS global (para todo el proyecto) INSTANCE_NAME.c.PROJECT_ID.internal

Reemplaza lo siguiente:

  • INSTANCE_NAME: El nombre de la instancia. 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.

Resolución de nombre del DNS

Las instancias 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 instancia (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 deGoogle Cloudcrea de forma automática registros PTR para instancias 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

La VM del cliente y la VM asociada con el registro DNS interno pueden ubicarse en proyectos separados, pero deben usar la misma red de VPC compartida. Por ejemplo, el cliente puede estar ubicado en un proyecto de servicio, y la VM asociada con el registro de DNS interno puede estar ubicada en un proyecto de servicio diferente o en el proyecto host.

Los clientes deben emitir consultas de nombres de dominio completamente calificados (FQDN) para los registros de DNS internos en lugar de depender de consultas parciales y dominios de búsqueda de DNS. Los dominios de búsqueda de DNS son diferentes en cada proyecto por razones como las siguientes:

  • La parte del nombre de dominio de cada registro A de DNS interno contiene el ID del proyecto que contiene la VM. En el caso de una VM en un proyecto de servicio cuya interfaz de red nic0 usa una red de VPC compartida, el proyecto de la VM es diferente del proyecto que contiene la red.

  • El uso de nombres de DNS internos zonales o globales (para todo el proyecto) depende de la configuración del proyecto que contiene la VM.

Para obtener más información sobre la VPC compartida, consulta los siguientes recursos:

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 para crear entradas de DNS personalizadas para tus instancias. Puedes configurar registros PTR que te permiten anular la URL de DNS interna predeterminada para tu instancia 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 instancias, consulta Crea un registro PTR para una instancia.

Nombres de host personalizados

Puedes especificar un nombre de host personalizado para una instancia 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 con un nombre de host personalizado.

DNS interno y DHCP

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. Las instancias 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 instancia. 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 instancias 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 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.

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

Reemplaza lo siguiente:

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

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

Reemplaza lo siguiente:

  • INSTANCE_NAME: Es el nombre de la instancia.
  • PROJECT_ID es el proyecto al que pertenece la instancia.

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?