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 entre instancias al resolver direcciones IP internas. Las redes de nube privada virtual de Google Cloud usan el servicio DNS interno para que las instancias de computación de la misma red puedan acceder entre sí mediante nombres DNS internos.

Google Cloud crea, actualiza y elimina automáticamente los siguientes tipos de registros DNS a medida que gestionas tus instancias:

• Los registros de direcciones DNS, o registros A, se crean para las instancias de una zona 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 eliminas una instancia, Google Cloud se eliminan automáticamente los registros A y PTR asociados a su nombre DNS interno. Si creas una instancia con el mismo nombre, Google Cloud crea registros nuevos para la sustitución.

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. Por lo tanto, el tipo de pila de la interfaz de red nic0 debe ser solo IPv4 o de pila dual. El DNS interno no admite interfaces de red que solo utilicen IPv6.

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

  • La dirección IPv4 interna principal de una interfaz de red distinta de nic0.
  • Una dirección IPv4 externa de cualquier interfaz de red.
  • Una dirección IPv4 interna de un intervalo de IPs de alias de cualquier interfaz de red.
  • Un intervalo de direcciones IPv6 internas o externas de cualquier interfaz de red.

• Para resolver nombres de DNS internos, la máquina virtual cliente y la máquina virtual asociada al registro DNS interno deben cumplir los siguientes requisitos:

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

  Para obtener más información sobre los casos prácticos de VPC compartida, consulta Nombres de DNS interno 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 en cada zona, pero puedes reutilizar los nombres de las instancias en diferentes zonas. Por ejemplo, puede tener varias instancias llamadas instance-1 siempre que estén en zonas diferentes.
• DNS global: los nombres de instancia deben ser únicos en cada proyecto. Con el DNS global, no puedes reutilizar nombres de instancias en el proyecto.

Google recomienda encarecidamente usar el DNS zonal porque ofrece una mayor fiabilidad al aislar los fallos en el registro de DNS en zonas individuales. En caso de interrupción, el DNS global tiene los siguientes problemas:

• El nombre de la instancia debe ser único en todo el proyecto. Por lo tanto, no puedes crear instancias en ninguna región que tenga errores en el plano de control y en la que tengas o hayas tenido recursos del proyecto. Google Cloud No puedes verificar los nombres de DNS de los recursos en la región no disponible.
• Algunas funciones de Compute Engine no están disponibles, como el autoescalado de los grupos de instancias gestionados (MIGs). Por lo tanto, tus aplicaciones que usan el autoescalado para gestionar correctamente los aumentos de carga de trabajo no pueden aumentar su escala.

El tipo de DNS interno predeterminado se define al habilitar la API Compute Engine.

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

Los nombres de dominio completos de los nombres de DNS internos se describen en la siguiente tabla.

Haz los cambios siguientes:

• INSTANCE_NAME: el nombre de la instancia. En el caso del DNS zonal, este valor debe ser único en la zona, pero se puede repetir en otras zonas. En el caso del DNS global, el nombre de la instancia debe ser único en todo el proyecto.
• ZONE: la zona en la que se encuentra tu instancia.
• PROJECT_ID: el proyecto al que pertenece la instancia.

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

Resolución de nombres de DNS

Las instancias reciben información de resolución de DNS interna como parte de sus concesiones 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 de DNS internos.

Zonas inversas de registros PTR

El servicio DNS interno deGoogle Cloudcrea automáticamente registros PTR para las instancias de las siguientes zonas inversas:

• 10.in-addr.arpa.
• 168.192.in-addr.arpa.
• 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... a través de 31.172.in-addr.arpa.

Nombres de DNS internos y VPC compartida

La VM cliente y la VM asociada al registro DNS interno pueden estar en proyectos distintos, pero deben usar la misma red de VPC compartida. Por ejemplo, el cliente puede estar en un proyecto de servicio y la VM asociada al registro DNS interno puede estar en otro proyecto de servicio o en el proyecto del host.

Los clientes deben enviar consultas de nombres de dominio completos (FQDN) para los registros DNS internos en lugar de usar consultas parciales y dominios de búsqueda de DNS. Los dominios de búsqueda de DNS son diferentes en cada proyecto por motivos como los 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 de un proyecto de servicio cuya interfaz de rednic0 utilice 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 (de 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 artículos:

• Información general sobre las VPC compartidas
• Aprovisionar una VPC compartida

Personalizar nombres de DNS internos

Es posible que algunas organizaciones o aplicaciones requieran nombres de DNS internos personalizados en lugar de los nombres de DNS internos predeterminados creados por Google Cloud.

Zonas privadas y registros personalizados con Cloud DNS

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

Para crear registros PTR personalizados que anulen los nombres PTR de DNS internos creados automáticamente, consulta Registros PTR de direcciones RFC 1918 en zonas privadas. Para obtener información sobre cómo crear registros PTR para instancias, consulta Crear un registro PTR para una instancia.

Nombres de host personalizados

Puede especificar un nombre de host personalizado para una instancia al crearla. Los nombres de host personalizados asignados de esta forma no se resuelven mediante DNS interno. Con los nombres de host personalizados, debes crear un registro DNS correspondiente en la zona adecuada (por ejemplo, con Cloud DNS). Para obtener más información, consulta Crear una instancia con un nombre de host personalizado.

DNS y DHCP internos

Las instancias de Compute Engine están configuradas para renovar las concesiones de DHCP cada 24 horas. En las instancias en las que está habilitado el DNS zonal, la concesión de DHCP caduca cada hora. Las instancias que usan DNS zonal tienen entradas zonales y globales en el archivo de configuración DHCP.

De forma predeterminada, la mayoría de las distribuciones de Linux almacenan la información de DHCP en resolv.conf. Si editas manualmente resolv.conf, se revertirá al DHCP predeterminado cada vez que caduque la concesión de DHCP en tu instancia. Para hacer modificaciones estáticas en el archivo resolv.conf, varias distribuciones de Linux permiten añadir elementos al principio o al final de la política de DHCP.

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

Consulta la documentación de tu sistema operativo para obtener información sobre cómo configurar ajustes de red DHCP y DNS personalizados. Por ejemplo, para Red Hat Enterprise Linux for SAP con servicios de alta disponibilidad y actualización 8.6, usa el siguiente enlace: Configurar manualmente el archivo /etc/resolv.conf

Archivo resolv.conf de ejemplo

De forma predeterminada, la mayoría de las distribuciones de Linux almacenan la información de DHCP en resolv.conf. El servicio systemd-resolved también proporciona servicios de resolución para DNS. Puedes configurar este servicio editando el archivo /etc/systemd/resolved.conf y otros archivos *.conf del 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 gestionar 6 registros, y Compute Engine proporciona 3 de ellos. Si añades entradas a la ruta de búsqueda de forma que el número total de entradas sea superior a 6, tu sistema operativo no aplicará las reglas de búsqueda posteriores a la 6.ª entrada.^th Esto puede provocar que las funciones de Compute Engine dejen de funcionar, como el acceso a las instancias mediante sus nombres.

• Si editas manualmente resolv.conf, se revertirá al DHCP predeterminado cada vez que caduque la concesión de DHCP de 24 horas en tu instancia. En las instancias que usan DNS zonales, la concesión de DHCP caduca cada hora. Para hacer modificaciones estáticas en el archivo resolv.conf, varias distribuciones de Linux permiten añadir elementos al principio o al final de la política de DHCP.

# 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

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

# 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

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

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 ejemplo:

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

Siguientes pasos

• Para obtener información sobre las Google Cloud redes de VPC, consulta la información general sobre VPC.
• Para obtener información sobre cómo crear y modificar redes de VPC, consulta Usar VPC.
• Migra tu organización y tus proyectos para usar DNS zonales en lugar de DNS globales.