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.
To view quotas or request quota increases, Cloud Identity and Access Management (Cloud IAM) members need one of the following roles.
|Check quotas for a project||Project owner or editor or Quota Viewer|
|Modify quotas, request additional quota||Project
owner or editor,
or custom role with the
Checking your quota
In the Cloud Console, go to the Quotas page.
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 outputs a
quota exceeded error
message and returns with the exit code
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.
- Go to the Quotas page.
- On the Quotas page, select the quotas that you want to change.
- Click the Edit Quotas button at the top of the page.
- Fill out your name, email, and phone number, and then click Next.
- Fill in your quota request, and then click Next.
- Submit your request.
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 a 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 service level agreement (SLA) for the type of resource. For more information, review the relevant 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.
|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.|
Unlike quotas, where you can request additional quota, limits cannot generally be increased unless specifically noted.
The number of API requests (queries) per day is governed at the project
level. All API requests count against this limit, including those made
gcloud command-line tool and through the Google Cloud Console.
|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 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
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.
Cloud DNS assigns every public managed zone to one of five nameserver
shards. Shards are the letter before the number in an authoritative nameserver
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
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:
- Check the nameservers for every subdomain zone to determine its shard.
- Find the shard (X) with the fewest (or least important) managed zones.
- Export zones in shard X (and change their delegations) to another DNS service.
- After TTLs expire for the original delegations, delete the managed zones for shard X subdomains.
- Create the managed zone for the parent domain; it is assigned to shard X.
- 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.