Políticas del servidor DNS

Una política de servidor DNS te permite configurar los servidores DNS que se van a usar al resolver nombres de dominio de tus Google Cloud recursos. Puedes usar políticas de servidor DNS para controlar la resolución de DNS en una red de nube privada virtual (VPC) específica. Una política de servidor DNS especifica el reenvío de DNS entrante, el reenvío de DNS saliente o ambos. Una política de servidor DNS entrante permite el reenvío de DNS entrante, mientras que una política de servidor DNS saliente es una forma de implementar el reenvío de DNS saliente.

También puedes configurar DNS64 para que las instancias de VM solo con IPv6 puedan comunicarse con destinos solo con IPv4.

Las subredes de VPC que solo usan IPv6 no admiten políticas de servidor DNS entrantes. Sin embargo, puedes configurar políticas de servidor DNS salientes para tus instancias de máquina virtual solo IPv6.

Políticas de servidor de entrada

Cada red de VPC proporciona servicios de resolución de nombres de Cloud DNS a las instancias de máquina virtual que tienen una interfaz de red (vNIC) conectada a la red de VPC. Cuando una VM usa su servidor de metadatos 169.254.169.254 como servidor de nombres, Google Cloud busca recursos de Cloud DNS según el orden de resolución del nombre de la red VPC.

Para que los servicios de resolución de nombres de una red de VPC estén disponibles en redes on-premise conectadas a la red de VPC mediante túneles de Cloud VPN, vinculaciones de VLAN de Cloud Interconnect o dispositivos Router, puedes usar una política de servidor entrante.

Cuando creas una política de servidor entrante, Cloud DNS crea puntos de entrada de la política de servidor entrante en la red de VPC a la que se aplica la política de servidor. Los puntos de entrada de la política de servidor entrante son direcciones IPv4 internas procedentes del intervalo de direcciones IPv4 principal de cada subred de la red de VPC aplicable, excepto las subredes con datos --purpose específicos, como las subredes solo de proxy de determinados balanceadores de carga y las subredes que usa Cloud NAT para NAT privada.

Por ejemplo, si tienes una red de VPC que contiene dos subredes en la misma región y una tercera subred en otra región, cuando configures una política de servidor entrante para la red de VPC, Cloud DNS usará un total de tres direcciones IPv4 como puntos de entrada de la política de servidor entrante, una por subred.

Para obtener información sobre cómo crear una política de servidor entrante para una VPC, consulta Crear una política de servidor entrante.

Red y región de las consultas entrantes

Para procesar las consultas de DNS que se envían a los puntos de entrada de la política de servidor entrante, Cloud DNS asocia la consulta a una red VPC y a una región:

  • La red de VPC asociada a una consulta de DNS es la red de VPC que contiene el túnel de Cloud VPN, la vinculación de VLAN de Cloud Interconnect o la interfaz de red del dispositivo Router que recibe los paquetes de la consulta de DNS.

    • Google recomienda crear una política de servidor entrante en la red VPC que se conecte a tu red local. De esta forma, los puntos de entrada de la política de servidor entrante se encuentran en la misma red de VPC que los túneles de Cloud VPN, las vinculaciones de VLAN de Cloud Interconnect o los dispositivos de router que se conectan a la red local.

    • Es posible que una red local envíe consultas a puntos de entrada de políticas de servidor entrantes en otra red de VPC. Por ejemplo, si la red de VPC que contiene los túneles de Cloud VPN, las vinculaciones de VLAN de Cloud Interconnect o los dispositivos Router que se conectan a la red local también está conectada a otra red de VPC mediante el emparejamiento entre redes de VPC. Sin embargo, no recomendamos usar esta configuración porque la red VPC asociada a las consultas de DNS no coincide con la red VPC que contiene los puntos de entrada de la política de servidor entrante, lo que significa que las consultas de DNS no se resuelven mediante las zonas privadas de Cloud DNS y las políticas de respuesta de la red VPC que contiene la política de servidor entrante. Para evitar confusiones, te recomendamos que sigas estos pasos de configuración:

      1. Crea una política de servidor entrante en la red de VPC que se conecte a la red local mediante túneles de Cloud VPN, vinculaciones de VLAN de Cloud Interconnect o dispositivos router.
      2. Configura los sistemas on-premise para que envíen consultas de DNS a los puntos de entrada de la política del servidor de entrada configurados en el paso anterior.

      3. Configura los recursos de Cloud DNS autorizados para la red de VPC que se conecta a la red local. Utiliza uno o varios de los siguientes métodos:

        • Añade la red de VPC que se conecta a la red local a la lista de redes autorizadas de las zonas privadas de Cloud DNS que están autorizadas para la otra red de VPC: si una zona privada de Cloud DNS y la red de VPC que se conecta a la red local están en proyectos diferentes de la misma organización, utiliza la URL completa de la red al autorizarla. Para obtener más información, consulta Configurar la vinculación entre proyectos.
        • Zonas de emparejamiento de Cloud DNS autorizadas para la red de VPC que se conecta a la red local: define la red de destino de la zona de emparejamiento como la otra red de VPC. No importa si la red de VPC que se conecta a la red on-premise está conectada a la red de VPC de destino de la zona de emparejamiento mediante el emparejamiento entre redes de VPC, ya que las zonas de emparejamiento de Cloud DNS no dependen del emparejamiento entre redes de VPC para la conectividad de red.

    • Si una red local envía consultas a una política de servidor entrante mediante el peering de redes de VPC, la red con la política de servidor entrante debe contener una máquina virtual, una vinculación de VLAN o un túnel de Cloud VPN ubicado en la misma región que las consultas entrantes.

  • La región asociada a una consulta de DNS es siempre la región que contiene el túnel VPN de Cloud, la vinculación de VLAN de Cloud Interconnect o la interfaz de red del dispositivo Router que recibe los paquetes de la consulta de DNS, no la región de la subred que contiene el punto de entrada de la política del servidor entrante.

    • Por ejemplo, si los paquetes de una consulta de DNS entran en una red VPC mediante un túnel VPN de Cloud ubicado en la región us-east1 y se envían a un punto de entrada de una política de servidor entrante en la región us-west1, la región asociada a la consulta de DNS es us-east1.
    • Como práctica recomendada, envía consultas DNS a la dirección IPv4 de un punto de entrada de una política de servidor entrante en la misma región que el túnel de Cloud VPN, la vinculación de VLAN de Cloud Interconnect o el dispositivo de router.
    • La región asociada a una consulta DNS es importante si usas políticas de enrutamiento por geolocalización. Para obtener más información, consulta Gestionar políticas de enrutamiento de DNS y comprobaciones de estado.

Anuncio de ruta del punto de entrada de la política del servidor entrante

Como las direcciones IP del punto de entrada de la política de servidor entrante se toman de los intervalos de direcciones IPv4 principales de las subredes, los routers de Cloud anuncian esas direcciones IP cuando la sesión del protocolo de pasarela fronteriza (BGP) de un túnel de Cloud VPN, una vinculación de VLAN de Cloud Interconnect o un dispositivo Router se configura para usar el modo de anuncio predeterminado del router de Cloud. También puedes configurar una sesión BGP para que anuncie las direcciones IP de los puntos de entrada de la política de servidor entrante si usas el modo de anuncio personalizado de Cloud Router de una de las siguientes formas:

  • Anuncias intervalos de direcciones IP de subred además de tus prefijos personalizados.
  • Incluyes direcciones IP de puntos de entrada de políticas de servidor entrantes en tus anuncios de prefijo personalizados.

Políticas de servidores de salida

Puedes modificar el orden de resolución de nombres de Cloud DNS de una red VPC creando una política de servidor saliente que especifique una lista de servidores de nombres alternativos. Cuando una VM usa su servidor de metadatos 169.254.169.254 como servidor de nombres y has especificado servidores de nombres alternativos para una red VPC, Cloud DNS envía todas las consultas a los servidores de nombres alternativos a menos que las consultas coincidan con una política de respuesta o una zona privada de ámbito de clúster de Google Kubernetes Engine.

Cuando hay dos o más servidores de nombres alternativos en una política de servidor saliente, Cloud DNS clasifica los servidores de nombres alternativos y los consulta tal como se describe en el primer paso del orden de resolución de nombres de VPC. Importante: Revisa detenidamente el orden de resolución de la red VPC. El uso de servidores de nombres alternativos inhabilita la resolución de muchas funciones de Cloud DNS y también puede afectar a la resolución de consultas de DNS públicas, en función de la configuración de los servidores de nombres alternativos. Para obtener más información sobre otras estrategias de reenvío de DNS saliente, consulta los métodos de reenvío de DNS en la descripción general de Cloud DNS. Para obtener información sobre cómo crear políticas de servidor saliente, consulta el artículo Crear una política de servidor saliente.

Tipos, métodos de enrutamiento y direcciones de servidores de nombres alternativos

Cloud DNS admite los siguientes servidores de nombres alternativos y ofrece métodos de enrutamiento estándar o privado para la conectividad.

Tipo de servidor de nombres alternativo Compatibilidad con el enrutamiento estándar Compatibilidad con el enrutamiento privado Intervalo de direcciones de origen de la consulta

Servidor de nombres de tipo 1

Una dirección IP interna de una máquina virtual Google Cloud en la misma red de VPC en la que se define la política de servidor saliente.

 Solo direcciones IP RFC 1918: el tráfico siempre se enruta a través de una red de VPC autorizada. Cualquier dirección IP interna, como una dirección privada RFC 1918, una dirección IP privada que no sea RFC 1918 o una dirección IP externa reutilizada de forma privada, excepto una dirección IP de servidor de nombres alternativa prohibida: el tráfico siempre se enruta a través de una red de VPC autorizada. 35.199.192.0/19

Servidor de nombres de tipo 2

Una dirección IP de un sistema on-premise conectado a la red VPC con la política de servidor saliente mediante Cloud VPN o Cloud Interconnect.

 Solo direcciones IP RFC 1918: el tráfico siempre se enruta a través de una red de VPC autorizada. Cualquier dirección IP interna, como una dirección privada RFC 1918, una dirección IP privada que no sea RFC 1918 o una dirección IP externa reutilizada de forma privada, excepto una dirección IP de servidor de nombres alternativa prohibida: el tráfico siempre se enruta a través de una red de VPC autorizada. 35.199.192.0/19

Servidor de nombres de tipo 3

Una dirección IP externa de un servidor de nombres de DNS accesible a Internet o la dirección IP externa de un recurso, como la dirección IP externa de una VM en otra red de VPC. Google Cloud

Solo direcciones IP externas enrutables por Internet: el tráfico siempre se enruta a Internet o a la dirección IP externa de un Google Cloud recurso. No se admite el enrutamiento privado. Intervalos de origen de Google Public DNS

Cloud DNS ofrece dos métodos de enrutamiento para consultar servidores de nombres alternativos:

  • Enrutamiento estándar. Cloud DNS determina el tipo de servidor de nombres alternativo mediante su dirección IP y, a continuación, usa el enrutamiento privado o público:

    • Si el servidor de nombres alternativo es una dirección IP RFC 1918, Cloud DNS clasifica el servidor de nombres como tipo 1 o tipo 2 y enruta las consultas a través de una red de VPC autorizada (enrutamiento privado).
    • Si el servidor de nombres alternativo no es una dirección IP RFC 1918, Cloud DNS clasifica el servidor de nombres como Tipo 3 y espera que el servidor de nombres alternativo sea accesible a través de Internet. Cloud DNS enruta las consultas a través de Internet (enrutamiento público).

  • Enrutamiento privado. Cloud DNS trata el servidor de nombres alternativo como Tipo 1 o Tipo 2. Cloud DNS siempre enruta el tráfico a través de una red de VPC autorizada, independientemente de la dirección IP del servidor de nombres alternativo (RFC 1918 o no).

Direcciones IP de servidores de nombres alternativos prohibidas

No puedes usar las siguientes direcciones IP para los servidores de nombres alternativos de Cloud DNS:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Requisitos de red de servidores de nombres alternativos

Los requisitos de red de los servidores de nombres alternativos varían en función del tipo de servidor de nombres alternativo. Para determinar el tipo de un servidor de nombres alternativo, consulta Tipos, métodos de enrutamiento y direcciones de servidores de nombres alternativos. A continuación, consulta una de las siguientes secciones para ver los requisitos de red.

Requisitos de red de los servidores de nombres alternativos de tipo 1

Cloud DNS envía paquetes cuyas fuentes proceden del intervalo de direcciones IP 35.199.192.0/19 a la dirección IP del servidor de nombres alternativo de tipo 1. Google Cloud enruta los paquetes de las consultas mediante rutas de subred locales en la red de VPC. Asegúrate de que no has creado ninguna ruta basada en políticas cuyos destinos incluyan direcciones IP de servidores de nombres alternativos de tipo 1.

Para permitir los paquetes entrantes en las VMs de servidores de nombres alternativos, debes crear reglas de cortafuegos de VPC de entrada o reglas en políticas de cortafuegos con las siguientes características:

  • Destinos: deben incluir las VMs del servidor de nombres alternativo
  • Fuentes: 35.199.192.0/19
  • Protocolos: TCP y UDP
  • Puerto: 53

Cloud DNS requiere que cada servidor de nombres alternativo envíe paquetes de respuesta a la dirección IP de Cloud DNS en 35.199.192.0/19 desde la que se originó la consulta. Las fuentes de los paquetes de respuesta deben coincidir con la dirección IP del servidor de nombres alternativo al que Cloud DNS envía la consulta original. Cloud DNS ignora las respuestas si proceden de una fuente de direcciones IP inesperada, como la dirección IP de otro servidor de nombres al que un servidor de nombres alternativo podría reenviar una consulta.

Cuando un servidor de nombres alternativo de tipo 1 envía paquetes de respuesta a 35.199.192.0/19, utiliza una ruta de enrutamiento especial.

Requisitos de red de los servidores de nombres alternativos de tipo 2

Cloud DNS envía paquetes cuyas fuentes proceden del intervalo de direcciones IP 35.199.192.0/19 a servidores de nombres alternativos de tipo 2. Cloud DNS se basa en los siguientes tipos de rutas dentro de la red de VPC a la que se aplica la política de servidor saliente:

Para permitir los paquetes entrantes en los servidores de nombres alternativos de tipo 2, asegúrate de configurar reglas de cortafuegos de entrada que se apliquen a los servidores de nombres alternativos y a cualquier equipo de red local pertinente con funciones de cortafuegos. La configuración del cortafuegos debe permitir los protocolos TCP y UDP con el puerto de destino 53 y las fuentes 35.199.192.0/19.

Cloud DNS requiere que cada servidor de nombres alternativo envíe paquetes de respuesta a la dirección IP de Cloud DNS en 35.199.192.0/19 desde la que se originó la consulta. Las fuentes de los paquetes de respuesta deben coincidir con la dirección IP del servidor de nombres alternativo al que Cloud DNS envía la consulta original. Cloud DNS ignora las respuestas si proceden de una fuente de direcciones IP inesperada, como la dirección IP de otro servidor de nombres al que un servidor de nombres alternativo podría reenviar una consulta.

Tu red on-premise debe tener rutas para el destino 35.199.192.0/19 cuyos siguientes saltos sean túneles de Cloud VPN, vinculaciones de VLAN de Cloud Interconnect o Cloud Routers ubicados en la misma red de VPC y región desde las que Cloud DNS envía la consulta. Siempre que los saltos siguientes cumplan los requisitos de red y región, Google Cloud no requiere una ruta de retorno simétrica. Las respuestas de los servidores de nombres alternativos de tipo 2 no se pueden enrutar mediante ninguno de los siguientes saltos siguientes:

  • Siguientes saltos en Internet
  • Siguientes saltos en una red de VPC que es diferente de la red de VPC en la que se originaron las consultas
  • Saltos siguientes en la misma red de VPC, pero en una región diferente de la región de origen de las consultas

Para configurar las rutas 35.199.192.0/19 en tu red on-premise, usa el modo de anuncio personalizado de Cloud Router e incluye 35.199.192.0/19 como prefijo personalizado en las sesiones de BGP de los túneles de Cloud VPN, las vinculaciones de VLAN de Cloud Interconnect o los routers de Cloud Router que conecten tu red de VPC a la red on-premise que contenga el servidor de nombres alternativo de tipo 2. También puedes configurar rutas estáticas equivalentes en tu red local.

Requisitos de red de los servidores de nombres alternativos de tipo 3

Cloud DNS envía paquetes cuyas fuentes coinciden con los intervalos de origen de DNS público de Google a los servidores de nombres alternativos de tipo 3. Cloud DNS usa el enrutamiento público, por lo que no depende de ninguna ruta dentro de la red de VPC a la que se aplique la política de servidor saliente.

Para permitir los paquetes entrantes en los servidores de nombres alternativos de tipo 3, asegúrate de que la configuración del firewall que se aplica al servidor de nombres alternativo permita los paquetes de los intervalos de origen de Google Public DNS.

Siguientes pasos