Cloud DNS Resource Quotas

Overview

Cloud DNS enforces quotas on resource usage for a variety of reasons. For example, quotas protect the community of Google Cloud users by preventing unforeseen spikes in usage. Quotas also help users who are exploring Google Cloud with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas may increase automatically, based on your use of a product.

Permissions

To view quotas or request quota increases, IAM members need one of the following roles.

Task	Required Role
Check quotas for a project	Project owner or editor or Quota Viewer
Modify quotas, request additional quota	Project owner or editor, Quota Admin, or custom role with the serviceusage.quotas.update permission

Checking your quota

In the Cloud Console, go to the Quotas page.

Using the gcloud command-line tool, run the following command to check your quotas. Replace [PROJECT_ID] with your own project ID.

    gcloud compute project-info describe --project [PROJECT_ID]

To check your used quota in a region, run:

    gcloud compute regions describe example-region

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Google Cloud returns the following HTTP status code: HTTP 413 Request Entity Too Large.

Requesting additional quota

Request additional quota from the Quotas page in the Cloud Console. Quota requests take 24 to 48 hours to process.

1. Go to the Quotas page.

   Go to the Quotas page

2. In the Quotas page, select the quotas you want to change.
3. Click the Edit Quotas button at the top of the page.
4. Fill out your name, email, and phone number and click Next.
5. Fill in your quota request and click Next.
6. Submit your request.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, provided that resource is available. It's important to note that quotas do not guarantee resource availability. Even if you have available quota, you won't be able to create a new resource if it is not available. For example, you might have sufficient quota to create new regional, external IP address in the us-central1 region, but that would not be possible if there were no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare; however, resources within a zone can be depleted from time to time, typically without impact to the SLA for the type of resource. For more information, review the relevant Service Level Agreement (SLA) for the resource.

The following sections describe quotas and limits for Cloud DNS zones, records, and the size of resource records.

Number of queries per project

This table highlights important global quotas for each project. Refer to the quotas page for other quotas.

Item	Quota	Notes
Number of API queries per user, per 100 seconds	Quotas	The maximum number of API requests an IAM user can make to the Cloud DNS API within a 100 second time period.

Limits

Unlike quotas, where you can request additional quota, limits cannot generally be increased unless specifically noted.

API usage

The number of API requests (queries) per day is governed at the project level. All API requests count against this limit, including those made from the gcloud command-line tool and through the Google Cloud Console.

Resource limits

Item	Limit	Notes
Managed zones	10,000	Contact your GCP sales team if you need to increase this limit.
Resource records (RR) sets per managed zone	10,000	Contact your GCP sales team if you need to increase this limit.
Records per RR set	100	Contact your GCP sales team if you need to increase this limit.
Additions per change	1,000	Contact your GCP sales team if you need to increase this limit.
Deletions per change	1,000	Contact your GCP sales team if you need to increase this limit.
Resource record data size per change	100,000 bytes	Contact your GCP sales team if you need to increase this limit.
Number of label combinations	1,000	Contact your GCP sales team if you need to increase this limit.
Number of labels per managed zone	64 labels and 128 bytes per key or value	This limit cannot be increased.
Number of forwarding targets in a forwarding zone	50	This limit cannot be increased.
Number of forwarding targets in an alternative name server	50	This limit cannot be increased.
Number of networks per managed zone	100	Contact your GCP sales team if you need to increase this limit.
Number of policy resources per project	100	Contact your GCP sales team if you need to increase this limit.
Number of VPC networks bound to a policy resource	100	Contact your GCP sales team if you need to increase this limit.
Number of VPC networks bound to a private managed zone resource	100	Contact your GCP sales team if you need to increase this limit.
Number of managed zone resources bound to a VPC network	10,000	Contact your GCP sales team if you need to increase this limit.

You can run the following command to look up the limits for your project. The following example shows the total limits for the various types of objects in the my-project project. The totalRrdataSizePerChange is measured in bytes and the combined total of both the additions and deletions for a change.

gcloud dns project-info describe my-project

id: my-project,
kind: "dns#project",
number: "123456789012",
quota:
    kind: dns#quota,
    managedZones: 10000,
    resourceRecordsPerRrset: 10000,
    rrsetAdditionsPerChange: 1000,
    rrsetDeletionsPerChange: 1000,
    rrsetsPerManagedZone: 10000,
    totalRrdataSizePerChange: 100000,
    labelSets: 1000

You can find the name of your default project and additional projects at the top of the Home page in the Google Cloud Console.

Nameserver limits

Cloud DNS assigns every public managed zone to one of five nameserver shards. Shards are the letter before the number in an authoritative nameserver name, so ns-cloud-e1 through ns-cloud-e4 are the E shard.

Multiple zones with the same DNS name cannot be assigned to the same shard, so only five zones can be created with exactly the same DNS name (this limit exists across all projects and users in Google Cloud). Before Cloud DNS creates a fifth zone with the same DNS name and prevent anyone else from using that DNS name, it requires you to verify the domain with a TXT record.

Cloud DNS assigns different shards for zones with subdomain DNS names like domain.example and any.sub.domain.example, so there can be at most five levels of delegated zones for any subdomain hosted on Cloud DNS. Non-delegated subdomains and delegations hosted on other DNS services do not count against this limit.

You cannot create a managed zone for a parent domain when all shards are already used for child subdomains. Avoid this problem by always creating managed zones for parent domains before creating zones for their subdomains.

Otherwise, follow these steps to free up a shard for the parent domain:

1. Check the nameservers for every subdomain zone to determine its shard.
2. Find the shard (X) with the fewest (or least important) managed zones.
3. Export zones in shard X (and change their delegations) to another DNS service.
4. After TTLs expire for the original delegations, delete the managed zones for shard X subdomains.
5. Create the managed zone for the parent domain; it is assigned to shard X.
6. Restore the deleted managed zones for the subdomains, restoring subdomains before any of their own sub-subdomains. They are in new shards, so they all need updated delegations.

Note: Google Domains creates its own zones on shards for all domains registered through it. Shard restrictions and limits apply across these products, so a Google Domains registration uses one of the shards available for domain and subdomain zones in Cloud DNS. Conversely, if some domain has Cloud DNS zones with identical or subdomain DNS names on all the nameserver shards, you cannot register that domain with Google Domains until you free up a shard using the steps above.