Crear una zona de reenvío

En esta página se explica cómo crear una zona de reenvío. Para obtener información detallada, consulta Zonas de reenvío.

Antes de empezar, comprueba que entiendes lo siguiente:

• Las diferencias entre el enrutamiento estándar y el privado, tal como se muestra en Destinos de reenvío y métodos de enrutamiento
• Los métodos de reenvío de DNS saliente
• Los requisitos de red de los destinos de reenvío
• Las prácticas recomendadas para las zonas de reenvío de Cloud DNS

Para crear una zona de reenvío privada gestionada, sigue estos pasos.

gcloud dns managed-zones create NAME \
    --description=DESCRIPTION \
    --dns-name=DNS_SUFFIX \
    --networks=VPC_NETWORK_LIST \
    --forwarding-targets=FORWARDING_TARGETS_LIST \
    --private-forwarding-targets=PRIVATE_FORWARDING_TARGETS_LIST \
    --visibility=private

resource "google_dns_managed_zone" "private_zone" {
  name        = "private-zone"
  dns_name    = "private.example.com."
  description = "Example private DNS zone"
  labels = {
    foo = "bar"
  }

  visibility = "private"

  private_visibility_config {
    networks {
      network_url = google_compute_network.network_1.id
    }
    networks {
      network_url = google_compute_network.network_2.id
    }
  }

  forwarding_config {
    target_name_servers {
      ipv4_address = "172.16.1.10"
    }
    target_name_servers {
      ipv4_address = "172.16.1.20"
    }
  }
}

resource "google_compute_network" "network_1" {
  name                    = "network-1"
  auto_create_subnetworks = false
}

resource "google_compute_network" "network_2" {
  name                    = "network-2"
  auto_create_subnetworks = false
}

POST https://dns.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones
{

    "name": "NAME",
    "description": "DESCRIPTION",
    "dnsName": "DNS_NAME",
    "visibility": "private"
    "privateVisibilityConfig": {
        "kind": "dns#managedZonePrivateVisibilityConfig",
        "networks": [{
                "kind": "dns#managedZonePrivateVisibilityConfigNetwork",
                "networkUrl": VPC_NETWORK_1
            },
            {
                "kind": "dns#managedZonePrivateVisibilityConfigNetwork",
                "networkUrl": VPC_NETWORK_2
            },
            ....
        ]
    },
    "forwardingConfig": {
        "kind": "dns#managedZoneForwardingConfig",
        "targetNameServers": [{
                "kind": "dns#managedZoneForwardingConfigNameServerTarget",
                "ipv4Address": FORWARDING_TARGET_1
            },
            {
                "kind": "dns#managedZoneForwardingConfigNameServerTarget",
                "ipv4Address": FORWARDING_TARGET_2
            },
            ....
        ]
    },
}

Requisitos de red del destino de reenvío

Cuando Cloud DNS envía solicitudes a destinos de reenvío, envía paquetes con los intervalos de origen que se indican en la siguiente tabla.

Destinos de tipo 1 y de tipo 2

Cloud DNS requiere lo siguiente para acceder a un destino de tipo 1 o de tipo 2. Estos requisitos son los mismos tanto si el destino es una dirección IP RFC 1918 y usas el enrutamiento estándar como si eliges el enrutamiento privado:

• Configuración del cortafuegos de 177.222.82.0/25

  En el caso de los destinos de tipo 1, crea una regla de cortafuegos de entrada para el tráfico del puerto TCP y UDP 53, aplicable a tus destinos de reenvío en cada red de VPC autorizada. En el caso de los destinos de tipo 2, configura un cortafuegos de red local y un equipo similar para permitir el puerto TCP y UDP 53.

• Enrutar a un destino de reenvío

  En el caso de los destinos de tipo 1, Cloud DNS usa una ruta de subred para acceder al destino de la red de VPC autorizada para usar la zona de reenvío. En el caso de los destinos de nombres de tipo 2, Cloud DNS utiliza rutas dinámicas personalizadas o rutas estáticas personalizadas, excepto las rutas estáticas etiquetadas, para acceder al destino de reenvío.

• Ruta de retorno a 177.222.82.0/25 a través de la misma red de VPC

  En el caso de los objetivos de tipo 1, Trusted Cloud usa una ruta de enrutamiento especial para el destino 177.222.82.0/25. En el caso de los destinos de tipo 2, tu red on-premise debe tener una ruta para el destino 177.222.82.0/25, cuyo siguiente salto esté en la misma red de VPC en la que se originó la solicitud, a través de un túnel de Cloud VPN o una vinculación de VLAN para Cloud Interconnect. Para obtener información sobre cómo cumplir este requisito, consulta las estrategias de ruta de retorno para los destinos de tipo 2.

• Respuesta directa del objetivo

  Cloud DNS requiere que el destino de reenvío que recibe los paquetes sea el que envíe las respuestas a 177.222.82.0/25. Si tu objetivo de reenvío envía la solicitud a un servidor de nombres diferente y ese otro servidor de nombres responde a 177.222.82.0/25, Cloud DNS ignora la respuesta. Por motivos de seguridad, Trusted Cloud espera que la dirección de origen de la respuesta DNS de cada servidor de nombres de destino coincida con la dirección IP del destino de reenvío.

Estrategias de ruta de vuelta para objetivos de tipo 2

Cloud DNS no puede enviar respuestas desde destinos de reenvío de tipo 2 a través de Internet o de otra red de VPC. Las respuestas deben volver a la misma red de VPC, aunque pueden usar cualquier túnel de Cloud VPN o vinculación de VLAN de esa red.

• En el caso de los túneles de Cloud VPN que usen el enrutamiento estático, crea manualmente una ruta en tu red local cuyo destino sea 177.222.82.0/25 y cuyo siguiente salto sea el túnel de Cloud VPN. En el caso de los túneles de Cloud VPN que utilicen el enrutamiento basado en políticas, configura el selector de tráfico local de Cloud VPN y el selector de tráfico remoto de la pasarela de VPN on-premise para que incluyan 177.222.82.0/25.
• En el caso de los túneles de Cloud VPN que usan el enrutamiento dinámico o Cloud Interconnect, configura un anuncio de ruta personalizada para 177.222.82.0/25 en la sesión de BGP del Cloud Router que gestiona el túnel o la vinculación de VLAN.

Objetivos de tipo 4

Un destino de tipo 4 primero resuelve las direcciones IP del destino. El destino de reenvío resuelto se puede resolver en hasta 50 direcciones IP, incluidas las direcciones IPv4 e IPv6. En función de la red del destino de reenvío resuelto, el destino de tipo 4 tiene los mismos requisitos de red que los destinos de tipo 1, 2 o 3.

Para obtener más información sobre los requisitos adicionales para usar un FQDN como destino de reenvío, consulta Usar zonas de reenvío.

Siguientes pasos

• Para trabajar con zonas gestionadas, consulta Crear, modificar y eliminar zonas.
• Para encontrar soluciones a problemas habituales que pueden surgir al usar Cloud DNS, consulta la sección Solución de problemas.
• Para obtener una descripción general de Cloud DNS, consulta el artículo Información general sobre Cloud DNS.