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 Cloud 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 Cloud 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 Cloud 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 Cloud 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

API

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

{

  "name": "my-zone-name",
  "dnsName": "example.com.",
  "description": "A zone",
  "visibility": "public"
}

Where PROJECT_ID is your project ID. Click here to try it on the API Explorer

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.

For best practices on creating a private zone, see Best practices for Cloud DNS private zones.

Create a new private zone:

Console

  1. Go to the Create a DNS zone page in the Cloud 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.

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.

For best practices on creating a forwarding zone, see Best practices for Cloud DNS forwarding zones.

Console

  1. Go to the Create a DNS zone page in the Cloud 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 domain name 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.

Creating managed reverse lookup zones

A managed reverse lookup zone is a forwarding zone with a special managed-reverse-lookup attribute that instructs Cloud DNS to perform PTR lookup against Compute Engine DNS data.

You must set up managed reverse lookup zones for Cloud DNS to correctly resolve non-RFC 1918 PTR records of your VMs.

Console

  1. Go to the Create a DNS zone page in the Cloud 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. You must enter a DNS name ending with in-addr.arpa.

  5. Optionally, add a Description.

  6. Under Options, select Managed reverse lookup zone.

  7. Select the networks to which the private zone will be visible.

  8. Click Create.

gcloud

 gcloud beta dns managed-zones create example-ptr-zone \
     --dns-name="211.130.in-addr.arpa" \
     --description="ptr zone for 130.211.x.x" \
     --networks="default" \
     --visibility=private \
     --managed-reverse-lookup=true \

where

  • --dns-name is the DNS name of the reverse lookup zone, usually in the form of ${ip_block_in_reverse}.in-addr.arpa.
  • --networks is the list of networks where the PTR delegation applies. This should match the network(s) where the created VM (target of the PTR record) resides.
  • --visibility must be private for managed reverse lookup zones, as these zones are only queried in the context of the VPC.
  • --managed-reverse-lookup flag that indicates this zone is a managed reverse lookup zone.

Using non-RFC 1918 address ranges for your subnets

In order to use non-RFC 1918 address ranges for your subnets, contact your account team to get access. You must ensure that the zone boundaries and address ranges match when defining a broader in-addr.arpa zone covering multiple VPCs. If you have two VPCs with CIDR ranges of 10.0.1.0/24 and 10.0.2.0/24, the recommended setup requires two corresponding managed reverse lookup zones, 1.0.10.in-addr.arpa and 2.0.10.in-addr.arpa.

Creating or updating forwarding zones with private forwarding targets

For outbound DNS forwarding, Cloud DNS allows you to specify forwarding targets and private forwarding targets as described in DNS forwarding. Queries sent to private forwarding targets never traverse the internet, regardless of the targets' IP address range.

Console

  1. Go to the Create a DNS zone page in the Cloud 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. Under Options, select Forward queries to another server.

  7. Select the networks to which the private zone will be visible.

  8. Click Add item to add IPv4 addresses of the destination DNS server. You can add multiple IP addresses.

  9. To enable private forwarding for any of the public IP addresses you entered, check the box next to Enable under Private forwarding.

  10. Click Create.

gcloud

 gcloud beta dns managed-zones create non-rfc-1918-forwarding-zone \
     --dns-name="non-rfc-1918-example.com" \
     --description="forwarding zone to a non-rfc-1918 IP" \
     --networks="default,my-network" \
     --visibility=private \
     --forwarding-targets="8.8.8.8,8.8.4.4" \
     --private-forwarding-targets="4.3.2.1"

where

  • --dns-name is the domain name to be resolved by the forwarding zone.
  • --networks is the list of networks that can use the forwarding zone.
  • --visibility must be private for forwarding zones.
  • --forwarding-targets is a list of static IP addresses. The forwarding path of any targets listed under this flag is determined by internal logic; any non-RFC 1918 IP address uses the internet forwarding path.
  • --private-forwarding-targets is a list of static IP addresses for which the forwarded query is sent through the VPC.

Configuring a DNS policy to enable forwarding to a non-RFC 1918 IP address

You can configure a DNS policy that enables outbound forwarding to a non-RFC 1918 IP address. It instructs your VPC network to use an alternative name server.

gcloud

 gcloud beta dns policies create non-rfc-1918-forwarding-policies \
     --project="my-project" \
     --description="non-RFC 1918 IP alternative name server for the network" \
     --networks="my-vpc-network" \
     --alternative-name-servers="8.8.8.8,8.8.4.4" \
     --private-alternative-name-servers="4.3.2.1"

where

  • --project is the project ID.
  • --networks is the name of the VPC network this policy applies to.
  • --alternative-name-servers is a list of static IP addresses for the alternative name servers. Forwarding path of alternative name servers listed under this flag is determined by internal logic; any non-RFC 1918 IP address uses the internet forwarding path.
  • --private-alternative-name-servers is a list of static IP addresses for which the forwarded query is sent through the VPC.

Requirements: For a 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.
  • 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.

In addition, you should be aware of the following:

  • All queries sent from Google Cloud 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.
  • Google Cloud 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, Google Cloud 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.
  • A managed private forwarding zone's forwarding targets cannot be reached transitively through VPC Network Peering. See the limitations section for a workaround.

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 Cloud 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 must be 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 must be 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 Google Cloud 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.
  • Google Cloud 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, Google Cloud 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

Оцените, насколько информация на этой странице была вам полезна:

Оставить отзыв о...

Текущей странице
Cloud DNS Documentation