Fix DNS "Over Quota" Error on Cloud DNS (2026)

Cloud DNS is reporting an "Over Quota" error because you’ve exceeded the maximum number of DNS records allowed for your project. This isn’t about how much data you’re transferring, but rather the sheer number of individual DNS entries you’ve configured.

Common Causes and Fixes for "Over Quota" Errors:

1. Duplicate Records: You’ve accidentally created multiple identical records for the same hostname and type (e.g., two A records for www.example.com pointing to the same IP).

   • Diagnosis: Use gcloud dns record-sets list --zone=YOUR_ZONE_NAME. Look for identical name, type, and rrdatas entries.
   • Fix: Delete the duplicate records.

     gcloud dns record-sets transaction start --zone=YOUR_ZONE_NAME
     gcloud dns record-sets remove --name=www.example.com. --type=A --ttl=300 --zone=YOUR_ZONE_NAME --data=192.0.2.1 # Use the exact values from the duplicate record
     gcloud dns record-sets transaction execute --zone=YOUR_ZONE_NAME
     

   • Why it works: Each record consumes a slot in the quota. Removing exact duplicates frees up those slots.

2. Wildcard Records with Many Subdomains: A single wildcard record (e.g., *.example.com) can, in theory, cover an infinite number of subdomains. Cloud DNS, however, counts these as a single record until a query for a specific subdomain triggers its creation. If you have many distinct subdomains actively being queried (and thus implicitly created), you might hit the quota.

   • Diagnosis: Check for wildcard records (* in the name field) in gcloud dns record-sets list --zone=YOUR_ZONE_NAME. Also, examine your application’s behavior to see if it relies on a vast number of dynamically generated subdomains.
   • Fix: If possible, replace wildcard records with specific records for the subdomains that are actually in use. If you truly need broad coverage and are hitting the quota, you’ll need to request a quota increase.

     # Example: If *.example.com is causing issues and only app1.example.com and app2.example.com are used
     gcloud dns record-sets transaction start --zone=YOUR_ZONE_NAME
     gcloud dns record-sets remove --name='*.example.com.' --type=A --ttl=300 --zone=YOUR_ZONE_NAME --data=192.0.2.1
     gcloud dns record-sets add --name=app1.example.com. --type=A --ttl=300 --zone=YOUR_ZONE_NAME --data=192.0.2.2
     gcloud dns record-sets add --name=app2.example.com. --type=A --ttl=300 --zone=YOUR_ZONE_NAME --data=192.0.2.3
     gcloud dns record-sets transaction execute --zone=YOUR_ZONE_NAME
     

   • Why it works: Specific records are counted individually, but a wildcard record, when not actively resolving unique subdomains, consumes less quota. By replacing the wildcard with specific entries for active subdomains, you manage the count more precisely.

3. Excessive CNAME Records: Each CNAME record counts against your total. If you’re using CNAMEs extensively, especially for many subdomains that themselves have CNAMEs, the count can escalate quickly.

   • Diagnosis: gcloud dns record-sets list --zone=YOUR_ZONE_NAME | grep CNAME
   • Fix: Consolidate CNAME records where possible. For example, if multiple subdomains point to the same target, consider having a single CNAME record that other CNAMEs can then point to (though this can impact DNS resolution performance and complexity). More practically, replace CNAMEs with A records if the target IP is static and known.

     # Example: Replacing a CNAME with an A record
     gcloud dns record-sets transaction start --zone=YOUR_ZONE_NAME
     gcloud dns record-sets remove --name=service.example.com. --type=CNAME --ttl=300 --zone=YOUR_ZONE_NAME --data=target.example.com.
     gcloud dns record-sets add --name=service.example.com. --type=A --ttl=300 --zone=YOUR_ZONE_NAME --data=192.0.2.4 # IP of target.example.com
     gcloud dns record-sets transaction execute --zone=YOUR_ZONE_NAME
     

   • Why it works: CNAME records are still individual entries. Replacing them with A records (when appropriate) might not reduce the count directly if the target itself has an A record, but it can simplify the DNS tree and prevent indirect quota consumption if the target’s A record is also counted.

4. Large Number of TXT Records: TXT records are often used for domain verification (SPF, DKIM, DMARC, Google Search Console, etc.). Each verification can add one or more TXT records.

   • Diagnosis: gcloud dns record-sets list --zone=YOUR_ZONE_NAME | grep TXT
   • Fix: Review your TXT records. Remove any that are no longer needed for verification or email authentication. Consolidate SPF records if possible into a single record.

     # Example: Removing an old verification TXT record
     gcloud dns record-sets transaction start --zone=YOUR_ZONE_NAME
     gcloud dns record-sets remove --name=example.com. --type=TXT --ttl=300 --zone=YOUR_ZONE_NAME --data='"google-site-verification=old-code"'
     gcloud dns record-sets transaction execute --zone=YOUR_ZONE_NAME
     

   • Why it works: Each TXT record, regardless of its content length, occupies a slot. Removing unused ones directly frees up quota.

5. MX Records for Multiple Mail Servers: If you have a complex email setup with many mail servers for redundancy or load balancing, each MX record for a given priority level counts individually.

   • Diagnosis: gcloud dns record-sets list --zone=YOUR_ZONE_NAME | grep MX
   • Fix: Ensure you only have the necessary MX records. If you have multiple records at the same priority level for the same hostname, you might be able to consolidate them if your mail provider supports it, or at least ensure there are no accidental duplicates.

     # Example: Removing a redundant MX record
     gcloud dns record-sets transaction start --zone=YOUR_ZONE_NAME
     gcloud dns record-sets remove --name=example.com. --type=MX --ttl=300 --zone=YOUR_ZONE_NAME --data='10 mx.backup.example.com.'
     gcloud dns record-sets transaction execute --zone=YOUR_ZONE_NAME
     

   • Why it works: Each MX record is a distinct DNS entry that needs to be stored and served, thus counting against the total.

6. Exceeded Project Quota: You’ve legitimately reached the maximum number of records allowed for your project, which is typically 10,000 records per zone (or 1,000,000 for DNS zones in the Enterprise tier).

   • Diagnosis: After cleaning up the above, if you still receive the error, you’ve genuinely hit the limit. Check your current usage against the quota.
   • Fix: Request a quota increase from Google Cloud. Go to the Google Cloud Console -> IAM & Admin -> Quotas. Find "Cloud DNS API" and select "DNS record sets per zone". Click "EDIT QUOTAS" and submit a request with your desired limit.
   • Why it works: This is the only way to increase the hard limit imposed by Google Cloud for your project.

The next error you’ll likely encounter after fixing this is related to DNS propagation delays, where changes you’ve made are not yet reflected across the global DNS system.