Políticas del servidor DNS

Una política de servidor DNS le permite configurar qué servidores DNS utilizar al resolver nombres de dominio para su Google Cloud Recursos. Puede usar políticas de servidor DNS para controlar la resolución DNS dentro de una red de nube virtual privada (VPC) específica. Una política de servidor DNS especifica el reenvío DNS entrante, el reenvío DNS saliente o ambos. Una política de servidor DNS entrante permite el reenvío DNS entrante, mientras que una política de servidor DNS saliente es una forma de implementar el reenvío DNS saliente.

También puede configurar DNS64 ( Vista previa ) para permitir que las instancias de VM solo IPv6 ( Vista previa ) se comuniquen con destinos solo IPv4.

Las subredes de VPC solo IPv6 ( versión preliminar ) no admiten políticas de servidor DNS de entrada. Sin embargo, puede configurar políticas de servidor DNS de salida para sus instancias de máquina virtual solo IPv6 ( versión preliminar ).

Políticas de servidor entrante

Cada red de VPC proporciona servicios de resolución de nombres DNS en la nube a las instancias de máquinas virtuales (VM) 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 de nombres de red de VPC .

Para que los servicios de resolución de nombres de una red VPC estén disponibles para las redes locales que están conectadas a la red VPC mediante túneles VPN en la nube, conexiones VLAN de Cloud Interconnect o dispositivos de enrutador, puede usar una política de servidor entrante .

Al crear una política de servidor entrante, Cloud DNS crea puntos de entrada en la red de VPC donde se aplica. Estos puntos son direcciones IPv4 internas provenientes del rango de direcciones IPv4 principal de cada subred de la red de VPC correspondiente, excepto las subredes con datos --purpose , como las subredes solo de proxy para ciertos balanceadores de carga y las subredes utilizadas por Cloud NAT para NAT privada.

Por ejemplo, si tiene una red VPC que contiene dos subredes en la misma región y una tercera subred en una región diferente, cuando configura una política de servidor entrante para la red VPC, Cloud DNS usa 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, consulte Crear una política de servidor entrante .

Red y región para consultas entrantes

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

  • La red VPC asociada para una consulta DNS es la red VPC que contiene el túnel VPN en la nube, el adjunto de VLAN de Cloud Interconnect o la interfaz de red del dispositivo enrutador que recibe los paquetes para la consulta DNS.

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

    • Es posible que una red local envíe consultas a los puntos de entrada de la política de servidor entrante en una red de VPC diferente; por ejemplo, si la red de VPC que contiene los túneles de Cloud VPN, las conexiones 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 emparejamiento de red de VPC. Sin embargo, no recomendamos usar esta configuración porque la red de VPC asociada para las consultas DNS no coincide con la red de VPC que contiene los puntos de entrada de la política de servidor entrante, lo que significa que las consultas DNS no se resuelven mediante las zonas privadas de Cloud DNS y las políticas de respuesta en la red de VPC que contiene la política de servidor entrante. Para evitar confusiones, recomendamos los siguientes pasos de configuración:

      1. Cree una política de servidor entrante en la red VPC que se conecte a la red local mediante túneles VPN en la nube, conexiones VLAN de Cloud Interconnect o dispositivos de enrutador.
      2. Configure los sistemas locales para enviar consultas DNS a los puntos de entrada de la política del servidor entrante configurados en el paso anterior.

      3. Configure los recursos de Cloud DNS autorizados para la red de VPC que se conecta a la red local. Utilice uno o más de los siguientes métodos:

        • Agregue la red de VPC que se conecta a la red local a la lista de redes autorizadas para las zonas privadas de Cloud DNS 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 se encuentran en proyectos diferentes de la misma organización, use la URL completa de la red al autorizarla. Para obtener más información, consulte Configurar enlaces entre proyectos .
        • Zonas de emparejamiento de Cloud DNS autorizadas para la red de VPC que se conecta a la red local : Establezca la red de destino de la zona de emparejamiento en la otra red de VPC. No importa si la red de VPC que se conecta a la red local está conectada a la red de VPC de destino de la zona de emparejamiento mediante el emparejamiento de red de VPC, ya que las zonas de emparejamiento de Cloud DNS no dependen del emparejamiento de red de VPC para la conectividad de red.

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

  • La región asociada para una consulta DNS siempre es la región que contiene el túnel VPN en la nube, el adjunto de VLAN de interconexión en la nube o la interfaz de red del dispositivo enrutador que recibe los paquetes para la consulta 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 para una consulta DNS ingresan a una red VPC mediante un túnel Cloud VPN ubicado en la región us-east1 y se envían a un punto de entrada de política de servidor entrante en la región us-west1 , la región asociada para la consulta DNS es us-east1 .
    • Como práctica recomendada, envíe consultas DNS a la dirección IPv4 de un punto de entrada de política de servidor entrante en la misma región que el túnel VPN en la nube, el adjunto de VLAN de interconexión en la nube o el dispositivo enrutador.
    • La región asociada a una consulta DNS es importante si utiliza políticas de enrutamiento de geolocalización. Para obtener más información, consulte Administrar políticas de enrutamiento DNS y comprobaciones de estado .

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

Dado que las direcciones IP de los puntos de entrada de la política del servidor entrante se obtienen de los rangos de direcciones IPv4 principales de las subredes, los Cloud Routers anuncian dichas direcciones IP cuando la sesión del Protocolo de Puerta de Enlace Fronteriza (BGP) de un túnel VPN en la nube, una conexión VLAN de Cloud Interconnect o un dispositivo Router está configurada para usar el modo de anuncio predeterminado de Cloud Router. También puede configurar una sesión BGP para anunciar las direcciones IP de los puntos de entrada de la política del servidor entrante si usa el modo de anuncio personalizado de Cloud Router de una de las siguientes maneras:

  • Anuncia rangos de direcciones IP de subred además de sus prefijos personalizados.
  • Incluye las direcciones IP de entrada de la política del servidor entrante en tus anuncios de prefijo personalizados.

Políticas de servidor de salida

Puede modificar el orden de resolución de nombres de Cloud DNS de una red de VPC mediante la creación de una política de servidor de salida que especifique una lista de servidores de nombres alternativos . Cuando una máquina virtual utiliza su servidor de metadatos 169.254.169.254 como servidor de nombres, y si ha especificado servidores de nombres alternativos para una red de VPC, Cloud DNS envía todas las consultas a estos servidores, a menos que estas coincidan con una política de respuesta de ámbito de clúster de Google Kubernetes Engine o una zona privada de ámbito de clúster de GKE.

Cuando existen 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 como se describe en el primer paso del orden de resolución de nombres de VPC.Importante: Revise cuidadosamente el orden de resolución de la red VPC . El uso de servidores de nombres alternativos deshabilita la resolución de muchas funciones de Cloud DNS y también puede afectar la resolución de consultas DNS públicas, según la configuración de dichos servidores. Para obtener más información sobre otras estrategias de reenvío DNS saliente, consulte los métodos de reenvío DNS en la descripción general de Cloud DNS.Para obtener información sobre cómo crear políticas de servidor saliente, consulte Creación de una política de servidor saliente .

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

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

Tipo de servidor de nombres alternativo Soporte de enrutamiento estándar El enrutamiento privado admite Rango de direcciones de origen de la consulta

Servidor de nombres tipo 1

Una dirección IP interna de un Google Cloud VM en la misma red VPC donde está definida la política del servidor saliente.

 Solo direcciones IP RFC 1918: el tráfico siempre se enruta a través de una red 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 alternativo prohibida (el tráfico siempre se enruta a través de una red VPC autorizada).35.199.192.0/19

Servidor de nombres tipo 2

Una dirección IP de un sistema local, 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 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 alternativo prohibida : el tráfico siempre se enruta a través de una red VPC autorizada.35.199.192.0/19

Servidor de nombres tipo 3

Una dirección IP externa de un servidor de nombres DNS accesible a Internet o la dirección IP externa de un Google Cloud recurso, por ejemplo, la dirección IP externa de una máquina virtual en otra red de VPC.

 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. Rangos de origen del DNS público de Google

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 luego utiliza cualquiera privado o público enrutamiento:

    • Si el servidor de nombres alternativo es una dirección IP RFC 1918, Cloud DNS clasifica el servidor de nombres como un servidor de nombres Tipo 1 o Tipo 2 y enruta las consultas a través de una red VPC autorizada (enrutamiento privado).
    • Si el servidor de nombres alternativo no es una dirección IP RFC 1918, Cloud DNS lo clasifica como Tipo 3 y espera que 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 de Tipo 1 o Tipo 2. Cloud DNS siempre enruta el tráfico a través de una red 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 utilizar las siguientes direcciones IP para 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 del servidor de nombres alternativo

Los requisitos de red para servidores de nombres alternativos varían según el tipo de servidor. Para determinar el tipo de servidor de nombres alternativo, consulte Tipos de servidores de nombres alternativos, métodos de enrutamiento y direcciones . A continuación, consulte una de las siguientes secciones para conocer los requisitos de red.

Requisitos de red para servidores de nombres alternativos de tipo 1

Cloud DNS envía paquetes cuyas fuentes son de35.199.192.0/19 Rango de direcciones IP a la dirección IP del servidor de nombres alternativo tipo 1.Google Cloud Enruta paquetes para consultas mediante rutas de subred local en la red VPC. Asegúrese de no haber creado ninguna ruta basada en políticas cuyos destinos incluyan direcciones IP de servidor de nombres alternativo de tipo 1.

Para permitir paquetes entrantes en máquinas virtuales de servidores de nombres alternativos, debe crear reglas de firewall de VPC que permitan el ingreso o reglas en políticas de firewall con las siguientes características:

  • Objetivos: deben incluir las máquinas virtuales 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.35.199.192.0/19 Desde donde 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 provienen de una dirección IP inesperada; por ejemplo, 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 a35.199.192.0/19 , utiliza una ruta de enrutamiento especial .

Requisitos de red para servidores de nombres alternativos de tipo 2

Cloud DNS envía paquetes cuyas fuentes son de35.199.192.0/19 Rango de direcciones IP para servidores de nombres alternativos de tipo 2. Cloud DNS se basa en los siguientes tipos de rutas dentro de la red VPC a las que se aplica la política de servidor de salida:

Para permitir la entrada de paquetes en servidores de nombres alternativos de tipo 2 , asegúrese de configurar las reglas de firewall de entrada aplicables a los servidores de nombres alternativos y a cualquier equipo de red local relevante con funciones de firewall. La configuración efectiva del firewall debe permitir los protocolos TCP y UDP con el puerto de destino 53 .35.199.192.0/19 fuentes.

Cloud DNS requiere que cada servidor de nombres alternativo envíe paquetes de respuesta a la dirección IP de Cloud DNS.35.199.192.0/19 Desde donde 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 provienen de una dirección IP inesperada; por ejemplo, la dirección IP de otro servidor de nombres al que un servidor de nombres alternativo podría reenviar una consulta.

Su red local debe tener rutas para35.199.192.0/19 Destino cuyos próximos saltos son túneles VPN en la nube, conexiones VLAN de Cloud Interconnect o enrutadores en la nube ubicados en la misma red VPC y región desde la que Cloud DNS envía la consulta. Siempre que los próximos saltos cumplan con los requisitos de red y región, Google Cloud No requiere una ruta de retorno simétrica. Las respuestas de servidores de nombres alternativos de tipo 2 no pueden enrutarse mediante ninguno de los siguientes saltos siguientes:

  • Próximos saltos en Internet
  • Próximos saltos en una red VPC que es diferente de la red VPC donde se originaron las consultas
  • Próximos saltos en la misma red VPC pero en una región diferente de la región donde se originaron las consultas

Para configurar el35.199.192.0/19 rutas en su red local, use el modo de publicidad personalizado de Cloud Router e incluya35.199.192.0/19 como un prefijo personalizado en las sesiones BGP de los túneles VPN en la nube relevantes, los adjuntos de VLAN de interconexión en la nube o los enrutadores en la nube que conectan su red VPC a la red local que contiene el servidor de nombres alternativo de tipo 2. Alternativamente, puede configurar rutas estáticas equivalentes en su red local.

Requisitos de red para servidores de nombres alternativos de tipo 3

Cloud DNS envía paquetes cuyas fuentes coinciden con los rangos de origen de Google Public DNS a servidores de nombres alternativos de tipo 3. Cloud DNS utiliza enrutamiento público; no depende de ninguna ruta dentro de la red VPC a la que se aplica la política de servidor de salida.

Para permitir paquetes entrantes en servidores de nombres alternativos de tipo 3 , asegúrese de que la configuración de firewall efectiva que se aplica al servidor de nombres alternativo permita paquetes de los rangos de origen de DNS público de Google.

¿Qué sigue?