Descripción general del DNS interno

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Cuando creas instancias de Compute Engine, el DNS interno crea automáticamente un nombre DNS para la instancia. Este nombre DNS facilita la comunicación interna entre instancias al resolver direcciones IP internas. Redes de nube privada virtual en Google Cloud utilice el servicio DNS interno para permitir que las instancias informáticas de la misma red accedan entre sí mediante nombres DNS internos.

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

• Los registros de direcciones DNS, o registros A , se crean para instancias en una zona DNS para .internal .
• Los registros PTR de instancias, utilizados para la búsqueda DNS inversa, se crean en las zonas inversas correspondientes.

Por ejemplo, cuando eliminas una instancia, Google Cloud elimina automáticamente los registros A y PTR asociados para su nombre DNS interno. Si luego crea una instancia con el mismo nombre, Google Cloud crea nuevos registros para el reemplazo.

Limitaciones

• Compute Engine crea registros DNS internos de nombre A y PTR 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 doble pila. El DNS interno no admite interfaces de red solo IPv6 ( Vista previa ).

• 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 IP de alias de cualquier interfaz de red.
  • Un rango de direcciones IPv6 interno o externo de cualquier interfaz de red.

• La resolución de nombres DNS internos requiere que la máquina virtual del cliente y la máquina virtual asociada con el registro DNS interno sean ambas:

  • En la misma red VPC.
  • En el mismo proyecto (excepto para ciertos escenarios de VPC compartida).

  Para obtener más información sobre escenarios de VPC compartida, consulte Nombres DNS internos y VPC compartida .

Nombres DNS internos zonales y globales

Google Cloud tiene dos tipos de nombres DNS internos:

• DNS zonal : los nombres de las instancias deben ser únicos dentro de cada zona, pero puede reutilizar los nombres de las instancias entre zonas. Por ejemplo, puede tener varias instancias denominadas instance-1 siempre que las instancias estén en zonas diferentes.
• DNS global : los nombres de las instancias deben ser únicos dentro de cada proyecto. Con DNS global, no puede reutilizar nombres de instancias dentro del proyecto.

Google recomienda encarecidamente utilizar DNS zonal porque ofrece una mayor confiabilidad al aislar fallas en el registro de DNS en zonas individuales. En 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 puede crear nuevas instancias en ninguna región que experimente fallas en el plano de control donde tenga o haya tenido recursos del proyecto. Google Cloud No se pueden verificar los nombres DNS de recursos existentes en la región no disponible.
• Ciertas funciones de Compute Engine no están disponibles, como el escalado automático de grupos de instancias administrados (MIG). Como resultado, las aplicaciones que utilizan el escalado automático para manejar con elegancia los aumentos de carga de trabajo no pueden ampliarse.

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 su organización o proyecto independiente habilitó la API de Compute Engine antes del 6 de septiembre de 2018, el tipo de DNS interno predeterminado está configurado en DNS global.

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

Reemplace lo siguiente:

• INSTANCE_NAME : el nombre de la instancia. Para DNS zonal, este valor debe ser único dentro de la zona, pero puede repetirse entre zonas. Para DNS global, el nombre de la instancia debe ser único en todo el proyecto.
• ZONE : la zona donde se encuentra su 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 utiliza a nivel de proyecto o instancia, consulte configurar nombres DNS para su proyecto o instancias .

resolución de nombres 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 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

Google CloudEl servicio DNS interno de crea automáticamente 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 se pueden ubicar 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 DNS interno puede estar ubicada en un proyecto de servicio diferente o en el proyecto de host.

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

• La parte del nombre de dominio de cada registro DNS A interno contiene el ID del proyecto que contiene la máquina virtual. Para una VM en un proyecto de servicio cuya interfaz de red nic0 utiliza una red VPC compartida, el proyecto de la VM es diferente del proyecto que contiene la red.

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

Para obtener más información sobre VPC compartida, consulte:

• Descripción general de VPC compartida
• Aprovisionar VPC compartida

Personalización de nombres DNS internos

Algunas organizaciones o aplicaciones pueden requerir nombres DNS internos personalizados en lugar de los nombres 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. Puede configurar registros PTR que le permitan anular la URL DNS interna predeterminada para su instancia con la URL personalizada que proporcione.

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

Nombres de host personalizados

Puede especificar un nombre de host personalizado para una instancia cuando la crea. Los nombres de host personalizados asignados de esta manera no se resuelven mediante DNS interno. Con nombres de host personalizados, aún necesita crear un registro DNS correspondiente en la zona apropiada (por ejemplo, usando Cloud DNS). Para obtener más información, consulte crear una instancia con un nombre de host personalizado .

DNS interno y DHCP

Las instancias de Compute Engine están configuradas para renovar las concesiones de DHCP cada 24 horas. Para las instancias que están habilitadas para DNS zonal, la concesión de DHCP vence cada hora. Las instancias que utilizan 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 almacenan información de DHCP en resolv.conf . La edición manual resolv.conf hace que se revierta al DHCP predeterminado cada vez que caduca la concesión de DHCP en su instancia. Para realizar modificaciones estáticas en el archivo resolv.conf , varias distribuciones de Linux permiten anteponer o agregar elementos a la política DHCP .

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

Consulte la documentación de su sistema operativo para obtener información sobre cómo configurar ajustes de red DHCP y DNS personalizados. Por ejemplo, para Red Hat Enterprise Linux para SAP con HA y Update Services 8.6, utilice el siguiente enlace: Configuración manual del archivo /etc/resolv.conf

Ejemplo de archivo resolv.conf

De forma predeterminada, la mayoría de las distribuciones de Linux almacenan información de DHCP en resolv.conf . El servicio systemd-resolved también proporciona servicios de resolución para DNS. Puede configurar este servicio editando el archivo /etc/systemd/resolved.conf y otros archivos *.conf en el directorio /etc/systemd/resolved.conf.d/ . En distribuciones de Linux que almacenan información de DHCP en resolved.conf , puede ver las entradas 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 esos registros. Si agrega entradas a la ruta de búsqueda de manera que el número total de entradas sea mayor que 6, su sistema operativo no aplicará las reglas de búsqueda después de la ^sexta entrada. Esto puede hacer que las funciones de Compute Engine dejen de funcionar, como el acceso a instancias utilizando sus nombres de instancia.

• La edición manual resolv.conf hace que se revierta al DHCP predeterminado cada vez que caduca la concesión de DHCP de 24 horas en su instancia. En instancias que utilizan DNS zonal, la concesión de DHCP vence cada hora. Para realizar modificaciones estáticas en el archivo resolv.conf , varias distribuciones de Linux permiten anteponer o agregar elementos a la política 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;
}

Ejemplo de archivo dhclient.conf

Algunos sistemas operativos, como Debian 9, utilizan 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 nuevo dominio de búsqueda y 172.16.1.1 es la IP de su servidor DNS.

¿Qué sigue?

• Para información sobre Google Cloud Redes de VPC, consulte la descripción general de VPC .
• Para obtener información sobre la creación y modificación de redes VPC, consulte Uso de VPC .
• Migre su organización y sus proyectos para utilizar DNS zonal en lugar de DNS global .