Managing Zones

A managed zone is the container for all of your DNS records that share the same domain name, for example, example.com. Managed zones are automatically assigned a set of name servers when they are created to handle responding to DNS queries for that zone. A managed zone has quotas for the number of resource records that it can include.

Before you begin

The Cloud DNS API requires that you create a Cloud DNS project and enable the Cloud DNS API.

If you are creating an application that uses the REST API, you must also create an OAuth 2.0 client ID.

  1. If you don't already have one, sign up for a Google account.
  2. Enable the Cloud DNS API in the GCP Console. You can choose an existing Compute Engine or App Engine project, or you can create a new project.
  3. If you need to make requests to the REST API, you will need to create an OAuth 2.0 ID: Setting up OAuth 2.0.
  4. Note the following information in the project that you will need to input in later steps:
    • The client ID (xxxxxx.apps.googleusercontent.com).
    • The project ID that you wish to use. You can find the ID at the top of the Overview page in the GCP Console. You could also ask your user to provide the project name that they want to use in your app.

If you have not run the gcloud command-line tool previously, you must run the following command to specify the project name and authenticate with the GCP Console:

gcloud auth login

You can also specify the --project parameter for a command to operate against a different project for that invocation.

Creating managed zones

When you get started with Cloud DNS API, you must create a managed zone to contain your DNS records. The managed zone is connected to your Cloud DNS project. Note that when you create a zone, the new zone won't be used until you update your domain registration, or explicitly point some resolver at, or directly query, one of your zone's authoritative name servers.

To create a zone, you must provide the DNS zone name, a description, and a name to identify the zone. Use the --visibility flag to designate the managed zone as public or private and the --networks flag to indicate the VPC networks to which a private zone is visible.

Creating public zones

A managed zone is a container for DNS records of the same DNS name suffix. A managed zone has a set of name servers that accept and responds to queries.

Create a new managed public zone:

Console

  1. Go to the Create a DNS zone page in the GCP Console.

    Go to the Create a DNS zone page

  2. Choose Public for the Zone type.

  3. Enter a Zone name. For example, my-new-zone.

  4. Enter a DNS name suffix for the zone using a domain name that you own. For example, example.com.

  5. Under DNSSEC, select Off, On, or Transfer. For more information, see DNSSEC configuration.

  6. Click Create.

The Zone details page is displayed. The default NS and SOA records have been created for you.

gcloud

gcloud dns managed-zones create my-zone-name \
    --dns-name="example.com" \
    --description="A zone" \
    --visibility=public

Python

def create_zone(project_id, name, dns_name, description):
    client = dns.Client(project=project_id)
    zone = client.zone(
        name,  # examplezonename
        dns_name=dns_name,  # example.com.
        description=description)
    zone.create()
    return zone

Creating private zones

A managed zone is a container for DNS records of the same DNS name suffix. A private managed zone is a container of DNS records that is only visible from one or more VPC networks that you specify.

Create a new private zone:

Console

  1. Go to the Create a DNS zone page in the GCP Console.

    Go to the Create a DNS zone page

  2. Choose Private for the Zone type.

  3. Enter a Zone name. For example, my-new-zone.

  4. Enter a DNS name suffix for the zone using a domain name that you own. For example, example.com.

  5. Optionally, add a Description.

  6. Select the networks to which the private zone must be visible.

  7. Click Create.

gcloud

To create a private zone:

gcloud dns managed-zones create my-zone-name \
    --dns-name="example.com" \
    --description="A zone" \
    --visibility=private \
    --networks=default

Python

def create_zone(project_id, name, dns_name, description):
    client = dns.Client(project=project_id)
    zone = client.zone(
        name,  # examplezonename
        dns_name=dns_name,  # example.com.
        description=description)
    zone.create()
    return zone

If you receive an accessNotConfigured error, you must enable the Cloud DNS API.

Best practices for Cloud DNS private zones

Private zones host DNS records that are visible only inside your organization. Public zones on Cloud DNS are not covered in this document; public zones cover the organization's public IP records, such as DNS records for the public website, and they're not as relevant in a hybrid setup.

Use automation to allow teams to manage private zones in the Shared VPC host project

If you use Shared VPC networks within your organization, you must host all the private zones on Cloud DNS within the host project. All service projects automatically can access the records in private zones attached to the Shared VPC network.

The following diagram shows how private zones are hosted in a Shared VPC network:

Private zones hosted in a shared VPC network (click to enlarge)
Private zones hosted in a shared VPC network (click to enlarge)

If you want teams to set their own DNS records, we recommend that you automate DNS record creation. For example, you can create a web application or an internal API where users set their own DNS records under specific subdomains; the app verifies that the records comply with your organization rules. Alternatively, you can put your DNS configuration in a code repository such as Cloud Source Repositories in the form of Terraform or Cloud Deployment Manager descriptors and accept pull requests from teams. In both cases, a service account with DNS Admin IAM role in the host project can automatically deploy the changes after they've been approved.

If you use multiple VPC networks, use VPC Network Peering and DNS peering to make sure that data can pass and that DNS requests work between environments.

Set IAM roles using the principle of least privilege

Using the security principle of least privilege , give the right to change DNS records only to those in your organization who need to perform this task. Avoid using primitive roles, because they might give access to resources beyond those that the user requires. Cloud DNS offers permissions and roles that allow you to give read and write access that is specific to just DNS.

If it's important to separate the ability to create private DNS zones from the ability to create public zones, use the dns.networks.bindPrivateDNSZone permission.

Creating forwarding zones

A forwarding zone overrides normal DNS resolution of the specified zones. Instead, queries for the specified zones are forwarded to the listed forwarding targets.

Console

  1. Go to the Create a DNS zone page in the GCP Console.

    Go to the Create a DNS zone page

  2. Choose Private for the Zone type.

  3. Enter my-new-zone for the Zone name.

  4. Enter a DNS name suffix for the zone using a domain name that you own. For example, example.com.

  5. Optionally, add a Description.

  6. Select the networks to which the private zone must be visible.

  7. Select the box next to Forward queries to another server.

  8. Enter the forwarding target under Destination DNS servers.

    A forwarding target is a list of static IP addresses. These IP addresses can be RFC 1918 addresses if those addresses are reachable on the same VPC network or on a network reachable via VPN or Interconnect. Otherwise, they must be publicly reachable IP addresses.

  9. Click Create.

gcloud

 gcloud dns managed-zones create example-forwarding-zone \
     --dns-name="example.com" \
     --description="A zone" \
     --networks="default,my-network" \
     --visibility=private \
     --forwarding-targets="8.8.8.8,8.8.4.4"

where

  • --dns-name is the list of domains to be resolved by the forwarding zone.
  • --networks is the list of networks that can use the forwarding zone.
  • --visibility indicates whether the forwarding zone is public or private.
  • --forwarding-targets is a list of static IP addresses. These IP addresses can be RFC 1918 addresses if those addresses are reachable on the same VPC network or on a network reachable via VPN or Interconnect. Otherwise, they must be publicly reachable IP addresses.

Requirements: For an RFC 1918 (internal) forwarding target name server to process DNS requests from VMs in your VPC network, you must do the following:

  • Ensure the forwarding target name server is reachable from within your VPC network. You can test this by using dig with the @ operator to query that name server directly.
  • Ensure on-premises network firewall rules that apply to the name server permit packets whose sources are in 35.199.192.0/19.
  • Your on-premises network must have a route that directs traffic destined to 35.199.192.0/19 back to your VPC network, through your Cloud VPN tunnel, Dedicated Interconnect attachment (VLAN), or Partner Interconnect attachment (VLAN). Replies to DNS queries from your VPC network must be sent back to 35.199.192.0/19, but they cannot be sent over the Internet. For Cloud VPN tunnels that use static routing, you must manually create a route in your on-premises network whose destination is 35.199.192.0/19 and whose next hop is the VPN tunnel. In addition to adding this route, for Cloud VPN tunnels that use policy-based routing, you must configure the Cloud VPN's local traffic selector and the on-premises VPN gateway's remote traffic selector to include 35.199.192.0/19. For Cloud VPN tunnels that use dynamic routing, Dedicated Interconnect, or Partner Interconnect, you must configure a custom route advertisement on the associated Cloud Router.
  • Forwarding queries to targets located in another VPC network through a forwarding zone is not supported. You can use a peering zone for this purpose instead.

In addition, you should be aware of the following:

  • All queries sent from GCP VMs in your VPC network to RFC 1918 addresses are proxied through 35.199.192.0/19. Even though 35.199.192.0/19 is used by all customers, your on-premises name server only receives requests from your VPC network.
  • The 35.199.192.0/19 address range is only reachable from within your VPC network or on-premises network connected to your VPC network. If your on-premises network routes packets destined to 35.199.192.0/19 via the Internet, they are dropped.
  • GCP requires that the on-premises name server that receives the request be the one that sends the reply to 35.199.192.0/19. If your name server sends the request to a different name server, and that other name server responds to 35.199.192.0/19, the response is ignored. For security reasons, GCP expects the source address of the DNS reply to match the destination address of the request.
  • Cloud DNS caches results of outbound-forwarded queries for at most 60 seconds, or for the duration of the records' TTLs (whichever is shorter), as long as the target name servers are reachable. If the target name servers become unreachable, the results of outbound-forwarded queries are cached for the duration of their TTL. This applies to queries that are outbound-forwarded via forwarding zones and to queries that are outbound-forwarded to alternative name servers via a DNS server policy.

Requirements: For an external forwarding target name server to receive the forwarded DNS queries, you must ensure the external name servers are reachable from your VPC network.

Best practices for DNS forwarding zones

Cloud DNS offers DNS server policies and DNS forwarding zones to allow lookups of DNS names between your on-premises and GCP environment. You have multiple options for configuring DNS forwarding. The following section lists best practices for hybrid DNS setup. These best practices are illustrated in the Reference architectures for Hybrid DNS.

DNS forwarding cannot be used to forward between different GCP environments, regardless of which way they are interconnected. For that use case, use DNS peering.

Use forwarding zones to query on-premises servers

To make sure you can query DNS records in your on-premises environment, set up a forwarding zone for the domain that you're using on-premises for your corporate resources (such as corp.example.com). This approach is preferred over using a DNS policy that enables an alternative name server. It preserves access to Compute Engine internal DNS names, and public IP addresses are still resolved without an additional hop through an on-premises nameserver.

The traffic flow using this setup is shown in the reference architectures.

You should use alternative name servers only if all DNS traffic needs to be monitored on-premises, and if your requirements can't be met by private DNS logging.

Use DNS server policies to allow queries from on-premises

To allow on-premises hosts to query DNS records that are hosted in Cloud DNS private zones (for example, gcp.example.com), create a DNS server policy using inbound DNS forwarding. Inbound DNS forwarding allows your system to query all private zones in the project as well as internal DNS addresses and peered zones. Although you have a separate inbound forwarder IP address for each subnet, all DNS queries return identical responses and there is no latency difference. Your apps can send a request to any of those addresses.

The traffic flow using this setup is shown in the reference architectures.

Open GCP and on-premises firewalls to allow DNS traffic

Make sure DNS traffic is not filtered anywhere inside your VPC or on-premises. This includes:

  • Make sure your on-premises firewall passes queries from Cloud DNS. Cloud DNS sends queries from the 35.199.192.0/19 IP address range. DNS uses UDP port 53 or TCP port 53, depending on the size of the request or response.

  • Make sure your DNS server does not block queries. If your on-premises DNS server accepts requests only from specific IP addresses, make sure the range 35.199.192.0/19 is included.

  • Make sure traffic can flow from on-premises to your forwarding IP addresses. For inbound forwarding, make sure traffic flowing to the forwarding IP addresses from your on-premises DNS servers or other clients is not blocked by your on-premises firewall. You might have to create a firewall rule on your on-premises firewall to allow traffic from all clients on UDP port 53 to the forwarding IP address.

Use conditional forwarding for accessing DNS records from on-premises

With Cloud DNS, to access private records hosted on corporate DNS servers on-premises, you can only use forwarding zones. However, depending on what DNS server software you use, you might have multiple options for accessing the DNS records in GCP from on-premises. In each case, access to the records happens using inbound DNS forwarding:

  • Conditional forwarding: Using conditional forwarding means that your corporate DNS server forwards requests for specific zones or subdomains to the forwarding IP addresses on GCP. We recommend this approach, because it is the least complex and allows you to centrally monitor all DNS requests on the corporate DNS servers.

  • Delegation: If your private zone on GCP is a subdomain of the zone you use on-premises, you can also delegate this subdomain to the GCP name server by setting NS entries within your zone. When you use this setup, clients can talk to the forwarding IP addresses on GCP directly, so make sure the firewall passes these requests.

  • Zone transfers: If you use zone transfers, you can synchronize DNS records from Cloud DNS to your on-premises DNS servers regularly. You can then use your on-premises DNS servers as an authoritative source for Cloud DNSS records. This reduces the need for a stable connection for name resolution, but it comes at the risk of serving stale records if the zone is not re-synced on each change.

Use DNS peering to avoid outbound forwarding from multiple VPCs

Don't use outbound forwarding to your on-premises DNS servers from multiple VPCs, because it creates problems with the return traffic. Responses from your DNS servers are accepted by GCP only if they're routed to the VPC from which the query originated. However, queries from any VPC have the same 35.199.192.0/19 IP range as source. Therefore, responses can't be routed correctly unless you have completely separate environments on-premises.

The following diagram illustrates the problem with having multiple VPCs doing outbound forwarding:

Issues with multiple VPCs doing outbound forwarding (click to enlarge)
Issues with multiple VPCs doing outbound forwarding (click to enlarge)

We recommend that you set up DNS peering to the on-premises zones, for example, corp.example.com, through a single VPC on which you've configured outbound forwarding to on-premises nameservers. This setup is shown in the reference architectures section.

Understand the difference between DNS peering and VPC Network Peering

VPC Network Peering is not the same as DNS peering. VPC Network Peering allows VMs in multiple projects to reach each other, but it does not change name resolution. Resources in each VPC still follow their own resolution order. In contrast, through DNS peering, you can allow requests to be forwarded for specific zones to another VPC. This allows you to forward requests to different GCP environments, regardless of whether the VPCs are interconnected.

VPC Network Peering and DNS peering are also set up differently. For VPC Network peering, both VPCs need to set up a peering relationship to the other VPC. The peering is then automatically bi-directional.

DNS peering unidirectionally forwards DNS requests and does not require a bi-directional relationship between VPCs. A VPC network referred to as the DNS consumer network performs lookups for a Cloud DNS peering zone in another VPC network, which is referred to as the DNS producer network. Use Cloud Identity and Access Management to give permissions for users to peer with your DNS producer network. To set up DNS peering from a consumer VPC network, you require the DNS peer role for the producer VPC network's host project.

If you use auto-generated names, use DNS peering for internal zones

If you use the auto-generated names for VMs that are created by the internal DNS service, you can use DNS peering to forward the projectname.internal zones to other projects. You can aggregate all .internal zones in a hub project to make them all available from on-premises. However, DNS peering is non-transitive, so if you have multiple projects that want to use each other's internal DNS, you have to set up DNS peering in a mesh between all of them.

This mesh setup is shown in the following diagram:

DNS peering in a mesh setup (click to enlarge)
DNS peering in a mesh setup (click to enlarge)

If you have problems, follow the troubleshooting guide

The Cloud DNS troubleshooting guide provides instructions for resolving common errors that you might encounter when you set up Cloud DNS.

Creating peering zones

When two networks are peered they do not automatically share DNS information. With DNS peering, you can have one network (consumer network) forward DNS requests to another network (producer network). You can do this by creating a peering zone in the consumer network that forwards matching DNS requests to the producer network.

Console

  1. Go to the Create a DNS zone page in the GCP Console.

    Go to the Create a DNS zone page

  2. Choose Private for the Zone type.

  3. Enter my-new-zone for the Zone name.

  4. Enter a DNS name suffix for the zone using a domain name that you own. For example, example.com.

  5. Optionally, add a Description.

  6. Select the networks to which the private zone must be visible.

  7. Under DNS peering, select the box next to Enable DNS peering.

  8. Under Peer project, select a peer project.

  9. Under Peer network, select a peer network.

  10. Click Create.

gcloud

  1. If it does not exist already, create a private zone or forwarding zone in the network that can handle the DNS requests (producer network):
gcloud dns managed-zones create example-private-zone \
    --dns-name="example.com" \
    --description="This is the zone for example.com" \
    --networks="default,my-network" \
    --visibility=private

where

  • --dns-name holds the suffix to be resolved by the zone.
  • --description holds a short description for the zone.
  • --networks lists the networks in the project that can use this zone.
  • --visibility is set to private to create a private zone.
  1. Add resource records to the zone.

  2. In the producer network project, grant the dns.peer IAM role to the account that creates the peering zone in the other network. The account that creates the peering zone can be a service account or a user account. Skip this step if the account already has the project editor or project owner roles, or has dns.admin privileges.

    gcloud beta projects add-iam-policy-binding [PRODUCER_PROJECT] \
        --member=[SERVICE_ACCOUNT] \
        --role=roles/dns.peer
    

    where

    • [SERVICE_ACCOUNT] is in the format serviceAccount:test123@example.domain.com
  3. Create a peering zone in the consumer network that forwards DNS requests to the producer network. You do not specify the name of the private zone that handles the requests, just the network. Any zone in the producer network can handle the request.

    gcloud beta dns managed-zones create example-peering-zone \
        --account=[SERVICE_ACCOUNT] \
        --dns-name="example.com" \
        --description="This is the zone for example.com" \
        --networks=[CONSUMER_NETWORK] \
        --visibility=private \
        --target-network=[PRODUCER_NETWORK] \
        --target-project=[PRODUCER_PROJECT]
    

    where

    • --account=[SERVICE_ACCOUNT] is the service account that has the dns.peer role for the producer network. If omitted, the active account returned by gcloud auth list must be a 'dns.peer' role or higher, for example, owner/editor or dns.admin.
    • --dns-name holds the list of domains to be resolved by the peered zone.
    • --description holds a short description for the zone.
    • --networks=[CONSUMER_NETWORK] is the network where the peering zone is being created.
    • --visibility is set to private because peering zones can only be private.
    • --target-network=[PRODUCER_NETWORK] is the network that the peering zone is to be peered with.
    • --target-project=[PRODUCER_PROJECT] is the project containing the network that the peering zone is to be peered with.

Once everything is configured, log into an instance in the consumer network and make a DNS request for the zone you've configured. The peering zone should forward the request to the private zone in the producer network, which should reply with an IP address.

Updating managed zones

Once you have created a managed zone to contain your DNS records, you may want to update some of its properties. Currently you can only update the description and DNSSEC configuration for public zones.

To update a zone, you must provide the zone resource name (which cannot contain .—as opposed to the DNS name, which does) and the updated information associated with the zone:

gloud

gcloud dns managed-zones update --description="My zone" "myzonename"

Python

 BODY = {
      'name' : 'myzonename',
      'description' : 'My zone'
    }
    service = build('dns', 'v1')
    response = service.managedZones().create(project=PROJECT_NAME,
                                             body=BODY
                                             ).execute()
 

Changing networks for private zones

To change the networks to which a private zone is visible:

gcloud

gcloud dns managed-zones update my-zone-name \
    --networks default,newnetwork 

This command makes the private zone visible to the networks default and newnetwork. All networks to which the private zone was visible are replaced with the new list of networks.

Adding and updating labels for managed zones

You can add labels to a managed zone, and you can remove existing labels.

In the following examples, [KEY]:[VALUE] is an arbitrary key:value pair, such as Dept:Marketing or Project:project1.

Add labels when you create a managed zone

gcloud dns managed-zones create \
    --dns-name="example.com." \
    --labels [KEY]:[VALUE] \
    --description="A zone" "myzonename"

Add labels to an existing managed zone

This command adds a label to an existing managed zone.

gcloud dns managed-zones update \
    --labels [KEY]:[VALUE],[[KEY]:[VALUE]] \
    "myzonename"

Update values of label key:value pairs

This command updates the value of an existing key:value label pair. If the key does not already exist, a new key:value pair is created.

gcloud dns managed-zones update \
    --update-labels [KEY]:[VALUE],[[KEY]:[VALUE]] \
    "myzonename"

Remove label key:value pairs

This command removes the specified key:value label pair(s).

gcloud dns managed-zones update \
    --remove-labels [KEY]:[VALUE],[[KEY]:[VALUE]] \
    "myzonename"

Clear all label key value pairs

This command clears all labels.

gcloud dns managed-zones update \
    --clear-labels \
    "myzonename"

Listing managed zones

To list all of your zones within a project:

gcloud

gcloud dns managed-zones list

Python

def list_zones(project_id):
    client = dns.Client(project=project_id)
    zones = client.list_zones()
    return [zone.name for zone in zones]

Getting managed zone details

To get details about your managed zone, such as if you need to look up the associated name servers:

gcloud

gcloud dns managed-zones describe "myzonename"

Python

def get_zone(project_id, name):
    client = dns.Client(project=project_id)
    zone = client.zone(name=name)

    try:
        zone.reload()
        return zone
    except NotFound:
        return None

Deleting managed zones

To delete a zone, provide the zone name to the delete command:

gcloud

gcloud dns managed-zones delete "myzonename"

Note that only empty zones can be deleted. An empty managed-zone has only SOA and NS record-sets. You can easily empty a zone using the import command as follows:

touch empty-file
gcloud dns record-sets import -z "myzonename" --delete-all-existing empty-file
rm empty-file

Python

def delete_zone(project_id, name):
    client = dns.Client(project=project_id)
    zone = client.zone(name)
    zone.delete()

Using DNS server policies

A DNS server policy is a collection of Cloud DNS rules that govern the behaviors of the name servers that host your zone. You can use DNS server policies to:

  • Specify an alternative name server that handles all DNS queries from the specified VPC networks.
  • Enable or disable inbound forwarding of DNS queries from on-premises networks to VPC networks (the on-premise and VPC networks must be connected via Cloud VPN or Cloud Interconnect).

You can apply a DNS server policy to one or more VPC networks.

See DNS server policy for an overview.

Creating a DNS policy that enables inbound DNS forwarding

This policy enables inbound DNS forwarding for the default network in the project.

gcloud dns policies create my-policy --project=myproject \
    --description="Inbound DNS forwarding for default network" \
    --enable-inbound-forwarding \
    --networks=default

Listing the inbound forwarder IP Addresses

gcloud compute addresses list --filter='purpose = "DNS_RESOLVER"' \
    --format='csv[no-heading](address, subnetwork)'

Creating a DNS policy that enables an alternative name server

This policy instructs your VPC network to use an alternative name server located in an on-premises network.

gcloud dns policies create [OUTBOUND_POLICY_NAME] --project=[PROJECT_ID] \
    --description="Alternative nameservers for for the VPC network" \
    --networks=[NETWORK] \
    --alternative-name-servers="[ALTERNATIVE_NAMESERVERS]"

Replace the placeholders with appropriate values:

  • [OUTBOUND_POLICY_NAME] is the name of the outbound Cloud DNS policy.
  • [PROJECT_ID] is your project ID.
  • [NETWORK] is the name of your VPC network.
  • [ALTERNATIVE_NAMESERVERS] is a comma delimited list of the IP addresses for the alternative name server(s) in your on-premises network.

Requirements: For an RFC 1918 (internal) alternative name server to process DNS requests from VMs in your VPC network, you must do the following:

  • Ensure the alternative name server is reachable from within your VPC network. You can test this by using dig with the @ operator to query the alternative name server directly.
  • Ensure on-premises network firewall rules that apply to the alternative name server permit packets whose sources are in 35.199.192.0/19.
  • Your on-premises network must have a route that directs traffic destined to 35.199.192.0/19 back to your VPC network, through your Cloud VPN tunnel, Dedicated Interconnect attachment (VLAN), or Partner Interconnect attachment (VLAN). Replies to DNS queries from your VPC network must be sent back to 35.199.192.0/19, but they cannot be sent over the Internet. For Cloud VPN tunnels that use static routing, you must manually create a route in your on-premises network whose destination is 35.199.192.0/19 and whose next hop is the VPN tunnel. In addition to adding this route, for Cloud VPN tunnels that use policy-based routing, you must configure the Cloud VPN's local traffic selector and the on-premises VPN gateway's remote traffic selector to include 35.199.192.0/19. For Cloud VPN tunnels that use dynamic routing, Dedicated Interconnect, or Partner Interconnect, you must configure a custom route advertisement on the associated Cloud Router.

In addition, you should be aware of the following:

  • All queries sent from GCP VMs in your VPC network are proxied through 35.199.192.0/19. Even though 35.199.192.0/19 is used by all customers, your on-premises alternative name server only receives requests from your VPC network.
  • The 35.199.192.0/19 address range is only reachable from within your VPC network or on-premises network connected to your VPC network. If your on-premises network routes packets destined to 35.199.192.0/19 via the Internet, they are dropped.
  • GCP requires that the alternative name server that receives the request be the one that sends the reply to 35.199.192.0/19. If your alternative name server sends the request to a different name server, and that other name server responds to 35.199.192.0/19, the response is ignored.For security reasons, GCP expects the source address of the DNS reply to match the destination address of the request.

Requirements: For an external alternative name server to receive the forwarded DNS queries, you must ensure the external alternative name servers are reachable from your VPC network.

Listing DNS policies

gcloud --project=my-project dns policies list

Deleting a DNS policy

gcloud --project=my-project dns policies delete example-policy

Updating a DNS policy

gcloud --project=myproject dns policies update --networks="default, somenewnetwork"

Next steps

Trang này có hữu ích không? Hãy cho chúng tôi biết đánh giá của bạn:

Gửi phản hồi về...

Cloud DNS Documentation