# Cloud DNS

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/cloud-dns

## Quick definition

DNS stands for Domain Name System. Think of it as the internet's phone book. Cloud DNS is a managed service provided by cloud platforms like Google Cloud, AWS, and Azure. It translates easy-to-remember website names like example.com into the numerical IP addresses that computers use to find each other on a network. You don't have to set up or maintain your own DNS servers; the cloud provider handles that for you, making it fast, reliable, and scalable.

## Simple meaning

Imagine you want to send a letter to a friend who lives on a street called 'Oak Avenue.' You don't know the exact house number, but you know the street name. The postal service has a directory that translates 'Oak Avenue' into a specific zip code and a route number that mail carriers use. DNS works similarly for the internet. When you type a website name like 'google.com' into your browser, your computer needs to find the exact server that hosts that website. It doesn't know the server's numerical address, which is called an IP address, so it asks a DNS resolver. The resolver looks up 'google.com' in a distributed directory and returns the correct IP address, like 142.250.190.46. 

 Cloud DNS is a managed version of this service. Instead of you having to install, configure, and maintain your own DNS servers on physical hardware, a cloud provider like Google Cloud, AWS, or Azure runs the DNS infrastructure for you. They maintain a global network of DNS servers that are highly available, automatically scale to handle millions of queries, and integrate with other cloud services. For example, if you deploy a web application on a virtual machine in Google Cloud, you can use Cloud DNS to create a DNS record that maps your custom domain name (like 'myapp.com') to the public IP address of that virtual machine. When someone visits your site, Cloud DNS resolves the name to the correct IP address quickly, no matter where in the world they are. 

 The key difference between running your own DNS and using Cloud DNS is that cloud providers handle all the complexity. They ensure that your DNS records are propagated quickly to authoritative name servers around the globe. They also provide a web interface and an API for managing records, which makes automation easy. You only pay for the number of DNS zones and queries you use. For IT professionals, this means less time spent on infrastructure management and more time focusing on application development and business goals.

## Technical definition

Cloud DNS is a managed, authoritative Domain Name System (DNS) service that translates domain names into IP addresses. It is built on a global, distributed network of anycast DNS servers that provide low-latency resolution and high availability. The service is compliant with DNS standards such as RFC 1035, RFC 2181, and supports DNSSEC (Domain Name System Security Extensions) for data integrity and authenticity. 

 The architecture of Cloud DNS consists of several key components: managed zones, resource record sets, and authoritative name servers. A managed zone is a container for DNS records associated with a specific domain, such as example.com. Each zone is assigned a set of authoritative name servers that are spread across multiple geographic regions. These name servers are responsible for responding to DNS queries for the domain. Resource record sets define the actual mappings: A records map a domain to an IPv4 address, AAAA records map to IPv6 addresses, CNAME records provide aliases, MX records specify mail servers, TXT records hold arbitrary text data often used for verification, and NS records delegate authority to other name servers. 

 When a user types a domain name into a browser, the query first goes to a recursive resolver, often provided by an ISP or a public service like Google Public DNS. If the resolver does not have the answer cached, it queries the root name servers, then the TLD (Top-Level Domain) name servers, and finally the authoritative name servers for the domain. Cloud DNS hosts these authoritative name servers. The service uses anycast routing, meaning the same IP address is advertised from multiple locations worldwide. The user's query is automatically routed to the nearest operational name server, reducing latency. 

 Cloud DNS integrates deeply with other cloud services. For example, in Google Cloud, you can use Cloud DNS with Cloud Load Balancing to route traffic to healthy backend instances. You can create private zones that are only visible within a specific Virtual Private Cloud (VPC) network, allowing internal services to resolve each other by name without exposing them to the public internet. The service also supports alias records, which allow you to point a domain to a Google Cloud resource, such as a load balancer or a Cloud Storage bucket, using the resource's DNS name rather than a fixed IP address. 

 Automation and management are handled via the Cloud Console, gcloud command-line tool, and RESTful APIs. This allows integration into CI/CD pipelines. Real IT implementation often involves creating a public zone for a production domain, adding A records for web servers, CNAME records for subdomains like www, and TXT records for domain verification with email providers. DNSSEC can be enabled to protect against cache poisoning and spoofing attacks. Monitoring is available through metrics like query volume, response times, and error rates. 

 In an exam context for certifications like Google ACE, AWS Solutions Architect Associate, and Azure AZ-104, you need to understand the differences between public and private zones, how to delegate a domain to Cloud DNS, and how routing policies work (e.g., simple, weighted, geolocation-based in AWS Route 53). The service is considered highly reliable because it is backed by a Service Level Agreement (SLA) of 100% uptime for queries, which is critical for enterprise applications. Costs are based on the number of zones hosted and the volume of DNS queries, with a tiered pricing model.

## Real-life example

Think of Cloud DNS like a massive, automated phone directory for the entire internet. Imagine you are a new business owner and you want people to call your store. You get a phone number, but you don't just give people the number-you also get a memorable business name, like 'Joe's Bakery.' Now, instead of you having to write down everyone's phone number in a personal phone book and answer calls yourself, you hire a professional phone directory service. This service has operators all over the world. When someone in another city says 'I want to call Joe's Bakery,' the operator instantly looks up 'Joe's Bakery' in their digital directory and connects the call to your store's phone number. 

 In the old-school IT world, businesses had to run their own DNS servers. That is like you having to install a giant switchboard in your office, hire operators, and keep the directory updated by hand. If the power went out or the operator got sick, nobody could call you. With Cloud DNS, you are outsourcing that switchboard to a professional company that has dozens of operators in different cities, backup generators, and a team keeping the directory accurate 24/7. You just tell them 'my domain is mybakery.com and it points to this IP address,' and they handle the rest. 

 Let's say your bakery's website is hosted on a server in a cloud data center. You create a DNS A record that says 'mybakery.com' points to IP 203.0.113.10. Cloud DNS broadcasts this information to thousands of name servers around the world. When a customer in London types 'mybakery.com' into their browser, their local ISP resolver asks one of Cloud DNS's global servers that is physically close to London. Because the servers are anycast, the query goes to the nearest server, which responds with the correct IP address quickly. The customer's browser then connects directly to your server. This global distribution and automatic routing are why Cloud DNS is fast and resilient.

## Why it matters

Cloud DNS matters because it is the backbone of how users and services find each other on the internet and within cloud networks. Without DNS, you would have to remember and type in long IP addresses for every website, service, or API you use. For IT professionals, managing DNS correctly is critical for application availability, performance, and security. 

 In practical IT contexts, Cloud DNS enables several key scenarios. First, it provides a single source of truth for domain name resolution across hybrid and multi-cloud environments. You can manage DNS records for your on-premises servers and cloud resources from one place. Second, it supports traffic management. For example, weighted routing allows you to send a percentage of traffic to a new version of an application for testing, while geolocation routing sends users to the nearest regional server for lower latency. Third, it enhances security through DNSSEC, which cryptographically signs DNS records so clients can verify they are not being redirected to a malicious site. 

Cloud DNS integrates with other services like load balancers, SSL certificates, and identity management. If your DNS is misconfigured, your website could become unreachable, email delivery could fail, and your domain could be hijacked. That is why understanding Cloud DNS is not optional for cloud architects and system administrators. In an era where downtime costs thousands of dollars per minute, having a reliable, managed DNS service with a 100% uptime SLA is a foundational part of any production deployment.

## Why it matters in exams

Cloud DNS is a frequent topic in cloud certification exams because it touches on core networking concepts that every cloud professional must understand. For exams like the Google Cloud Associate Cloud Engineer (ACE) and Professional Cloud Architect (PCA), you need to know how to create and manage public and private zones, delegate domains, and use alias records to point to Google Cloud resources. The AWS Cloud Practitioner and Solutions Architect Associate exams focus heavily on Amazon Route 53, which is AWS's managed DNS service. You must understand hosted zones, routing policies (simple, weighted, latency-based, failover, geolocation), health checks, and how to integrate with ELB. 

 For the Azure AZ-104 exam, Azure DNS is covered, including creating DNS zones, record sets, and using Azure Private DNS for internal name resolution. The CompTIA Network+ and Security+ exams test general DNS concepts that apply to cloud services, such as DNS record types (A, AAAA, CNAME, MX, TXT), how recursive queries work, and DNS security issues like cache poisoning. 

 Exam questions often present a scenario where you need to choose the correct DNS configuration to achieve a specific goal. For example, you might be asked how to route users to the closest regional endpoint, how to ensure a domain remains accessible if one region goes down, or how to configure a private DNS zone for internal microservices communication. You should be comfortable reading YAML or JSON templates that define DNS records in Infrastructure as Code tools like Terraform. Common question types include multiple-choice about best practices, multiple-answer about correct record types for a given purpose, and drag-and-drop about the sequence of a DNS query. Mastery of Cloud DNS can make the difference between a pass and a fail, especially in architect-level exams where networking is a major domain.

## How it appears in exam questions

Exam questions about Cloud DNS typically fall into three patterns: scenario-based, configuration-based, and troubleshooting-based. 

 In scenario-based questions, you are given a business requirement and asked to select the best DNS solution. For instance: 'A company has a global e-commerce application deployed on VMs in us-east-1, eu-west-1, and ap-southeast-1. They want to direct users to the region with the lowest latency. Which AWS Route 53 routing policy should they use?' The correct answer is latency-based routing. Another common scenario: 'You need to allow internal VMs to resolve the hostname 'db.internal.company.com' without exposing the resolution to the internet. What should you create?' The answer is a private DNS zone associated with the VPC. 

 Configuration-based questions require you to know the exact parameters for creating DNS records. For example: 'You are migrating a domain example.com to Google Cloud DNS. You have created a public zone. What must you do at your domain registrar to complete the delegation?' The correct step is to update the NS records at the registrar to point to the Cloud DNS authoritative name servers. Or: 'Which AWS Route 53 record type should you use to map a domain name to an Elastic Load Balancer?' The answer is an A record with an alias target set to the load balancer DNS name. 

 Troubleshooting questions present a broken configuration. For instance: 'Users report that they can access your website using the IP address but not the domain name. The DNS zone has valid A records. What is the most likely cause?' The answer is that the domain registrar's NS records still point to the old nameserver, and the delegation is incomplete. Another example: 'A CNAME record for www.example.com is configured, but the domain fails to resolve. You check and find that an A record for the root domain (example.com) also exists. Why does this cause a problem?' The answer is that a CNAME record cannot coexist with any other record of the same name (except DNSSEC records) per DNS standards. Understanding these patterns and the underlying RFCs is key to scoring points on DNS questions.

## Example scenario

You work for a small business called 'GreenLeaf Landscaping.' They have a website hosted on a virtual machine in Google Cloud with a public IP address of 34.123.45.67. They own the domain 'greenleaf-landscaping.com.' The owner wants customers to be able to type the domain name into a browser and see the website. 

 You first create a public DNS zone named 'greenleaf-landscaping.com' in Google Cloud DNS. The service automatically generates four authoritative name server addresses, like ns-cloud-a1.googledomains.com. You then go to the domain registrar where the domain was purchased and update the NS records to these four addresses. This step is called delegation. 

 Next, you create an A record within the zone: the name '@' (representing the root domain) points to 34.123.45.67, and you set the TTL (Time to Live) to 300 seconds. You also create a CNAME record: 'www' points to 'greenleaf-landscaping.com.' This way, both the bare domain and the www subdomain work. 

 You test by using the nslookup command from your local machine. It returns the correct IP address. After a few hours for propagation, customers can access the site. A month later, the company adds a new online store subdomain 'shop.greenleaf-landscaping.com' hosted on a different server. You add another A record for 'shop' pointing to that server's IP. The entire process is managed through the Cloud Console without touching any physical hardware. This scenario illustrates the fundamental workflow of using Cloud DNS to make a custom domain accessible on the internet.

## Understanding Public and Private DNS Zones in Cloud DNS

Cloud DNS is Google Cloud's managed DNS service that provides authoritative DNS serving for domain names. The foundation of all DNS configuration is the zone: a container for DNS records that defines the namespace for which Cloud DNS provides authoritative answers. There are two primary zone types: public zones and private zones, and understanding their differences is critical for both real-world configuration and exam success.

A public zone makes DNS records visible to the internet. When you manage a domain like example.com using Cloud DNS, you create a public zone. This zone contains resource record sets such as A, AAAA, CNAME, MX, and TXT records. After creation, you delegate the domain to Cloud DNS's name servers by updating the registrar's NS records. This delegation allows anyone on the internet to query Cloud DNS and receive authoritative responses for your domain. Public zones are essential for running any internet-facing service, including websites, email servers, and APIs. In exams, you will often see scenarios where you need to configure a public zone for a new domain, then update NS records at the registrar. A common trap question involves assuming Cloud DNS automatically handles domain registration – it does not. You must separately register the domain and then delegate it.

A private zone is restricted to one or more Virtual Private Cloud (VPC) networks in your GCP project. DNS records in a private zone are only resolvable from instances within those authorized VPC networks. This is critical for internal service discovery, database connections, and microservices communication without exposing internal IP addresses or hostnames to the internet. For example, you can create a private zone for internal.company with A records mapping to private IP addresses of your Compute Engine instances. Private zones support DNS peering, allowing resolution across different VPC networks. When you associate a private zone with a VPC network, Cloud DNS acts as an authoritative server for that domain within the network. Exam questions frequently test the concept of private zones by asking which service allows internal DNS without public exposure. The correct answer is always a private zone, never a public zone or a third-party service. Private zones can overlap with public zones; Cloud DNS will prefer the private zone for queries originating within the authorized VPC. This is called "split horizon DNS" and is a high-level concept sometimes tested in the Google Cloud Professional Cloud Architect exam.

Both zone types support DNS Security Extensions (DNSSEC) to protect against spoofing. When enabled, Cloud DNS signs your zones and provides public keys for validation. However, DNSSEC must be configured explicitly; it is not enabled by default. In exams, you may be asked to identify the correct zone type for a given requirement. Always tie the requirement to visibility: if it must be internet-accessible, use a public zone; if it must remain inside a VPC, use a private zone. Also remember that a single domain can have both a public zone and a private zone, but they must be in separate managed zones. This dual-zone arrangement is common in hybrid architectures where internal services use private IPs and external customers use public IPs.

When creating zones, be aware of the soft limits. By default, you can create up to 1000 public zones and 1000 private zones per project. Record sets per zone are limited to 10,000. These limits are frequently referenced in exam scenarios as reasons to use a more efficient record design or to request a quota increase. Understanding zone types is not just memorization; it is about applying the right tool to the right network architecture problem.

## Managing Resource Record Sets (RRSets) in Cloud DNS

Resource Record Sets (RRSets) are the core of DNS functionality in Cloud DNS. Each record set defines a mapping from a domain name to one or more values, with a specific type and a Time to Live (TTL) value. Managing these records correctly ensures reliable name resolution, fast propagation, and minimal DNS-related issues. In exams, you are expected to know the most common record types, how to add or modify records using the gcloud command-line tool and the Cloud Console, and how TTL affects performance and failover.

The major record types you will encounter include A records (mapping hostname to IPv4 address), AAAA records (mapping hostname to IPv6 address), CNAME records (aliasing one name to another canonical name), MX records (specifying mail exchange servers), TXT records (arbitrary text, often used for domain verification and SPF records), and NS records (delegating name servers). Cloud DNS also supports SRV records for service discovery and PTR records for reverse DNS lookups. For internal use, private zones can host custom record types. In the exam, you may be given a scenario where you need to choose the correct record type. For instance, to point app.example.com to an external load balancer's IP, you would create an A record. To alias app.example.com to a Google Cloud Load Balancer's fully qualified domain name, you would use a CNAME. A common mistake is using a CNAME for the root domain (bare domain), which is not allowed per DNS standards; you must use an A or AAAA record for the root.

Managing records via gcloud is a key skill tested in the Google Associate Cloud Engineer and Professional Cloud Architect exams. The primary command is gcloud dns record-sets create, update, and delete. For example, to add an A record, you run: gcloud dns record-sets create www.example.com. --zone=example-zone --type=A --ttl=300 --rrdatas=192.0.2.1. The --ttl parameter is often overlooked but critical: a low TTL (e.g., 60 seconds) enables fast propagation when changing IPs but increases query load. A high TTL (e.g., 86400 seconds) reduces load but delays updates. Exam questions sometimes present logs showing stale DNS results; the solution is to decrease the TTL before a planned IP change. Another scenario involves bulk record imports; you can use --zone-file-format to import a BIND-style zone file. The command gcloud dns record-sets import --zone=example-zone --zone-file-format records.bind will replace all records in the zone with those from the file. Be cautious: import overwrites existing records unless you use --replace-origin-ns to retain delegation.

Record sets in Cloud DNS are immutable in the sense that you cannot directly edit a live record; you must delete and re-create or update it. The update command effectively does this atomically. For exam troubleshooting, know that if you delete a record set, the name will immediately stop resolving except for cached queries. Also, Cloud DNS enforces that at least two NS records must exist in a public zone for delegation. If you accidentally delete all NS records, the zone becomes non-delegated and queries will fail. The Cloud Console provides a visual editor, but the gcloud tool is more powerful for scripting and automation. You will often see exam questions that ask which command creates a CNAME record; the correct answer includes the --type=CNAME flag and a single rrdatas value (CNAME records only accept one target).

TTL management is also important for disaster recovery. If your primary site goes down, you might want to update an A record to point to a failover IP. A low TTL ensures clients pick up the new IP quickly. However, many ISPs cache aggressively and may not honor low TTLs. Understanding this nuance can help you choose the right strategy when answering exam questions about DNS failover. Finally, remember that Cloud DNS supports weighted record sets and geographic routing through the use of multiple A records with different weights, but this is managed via the Cloud DNS configuration, not through standard DNS policies. The exam sometimes tests the ability to differentiate between what Cloud DNS offers natively versus what requires an external DNS service.

## DNS Peering, Forwarding, and Server Policies in Cloud DNS

Cloud DNS offers advanced features that allow you to extend DNS resolution across VPC networks and to on-premises environments. The three key concepts are DNS peering, DNS forwarding, and DNS server policies. Each serves a different architectural need, and exam questions frequently ask you to select the correct approach for a given hybrid or multi-network setup. Understanding these features is essential for passing the Google Cloud Professional Cloud Architect exam and for designing scalable, secure DNS resolutions in enterprise environments.

DNS peering allows you to share DNS resolution between two VPC networks without making the zones public. When you set up DNS peering, a producer network (which has a private zone) can be peered with a consumer network. The consumer network can then resolve DNS names from the producer's private zone as if they were local. For example, if the producer network has a private zone for apps.internal, instances in the peered consumer network can resolve app1.apps.internal to its private IP. This is achieved using Cloud DNS peering zones. A common exam scenario is when a company has multiple VPC networks (e.g., dev, staging, prod) and wants central DNS management from a single network (the shared VPC host). The solution is to create private zones in the host project and peer those zones with each service project's VPC. The exam will test that you know to create a peering zone in the consumer project, not in the producer project. The consumer project's peering zone points to the producer project's private zone. This is often reversed by mistake.

DNS forwarding is used when you want to resolve DNS names that are not managed by Cloud DNS, such as on-premises DNS servers or third-party DNS providers. You configure a DNS forwarding zone that specifies a target DNS server (by IP address or another DNS name) and a list of VPC networks that will use this forwarding. For instance, to resolve queries for onprem.company from Compute Engine instances, you create a forwarding zone with a rule that sends queries for *.onprem.company to your on-premises DNS server's IP. The target must be reachable from the VPC network, meaning you need proper network connectivity (e.g., VPN or Cloud Interconnect). Exam questions might present a hybrid scenario where an application running in GCP needs to resolve names from a legacy data center. The correct solution is to create a DNS forwarding zone in the project that has the VPC, and ensure that the on-premises DNS server is reachable via a VPN tunnel. They may also test that DNS forwarding is unidirectional: it forwards queries from GCP to on-premises, but not the reverse. If you need bidirectional resolution, you need both DNS forwarding and either DNS peering or VPN-based resolution.

DNS server policies allow you to override the default name server order for inbound DNS queries in a VPC network. For example, you can configure the VPC to use a specific set of name servers (like a custom resolver or Cloud Domain) before falling back to the default Google DNS. This is especially useful when you want all DNS queries from a VPC to be filtered or inspected by a security appliance. DNS server policies are applied at the VPC network level and affect all instances in that network. However, they do not affect outbound DNS queries from instances; they only affect inbound resolution (i.e., when the instance itself queries a name). An exam question might describe a scenario where you need to enforce that all DNS queries go through a corporate DNS filtering server. The correct answer is to create a DNS server policy that sets the name server order to include the corporate server. You also need to ensure the corporate server is reachable and that you have added appropriate firewall rules.

When studying for exams, focus on the specific use cases: use DNS peering for sharing private zones across VPCs; use DNS forwarding for resolving on-premises names from GCP; use DNS server policies for altering the DNS resolution chain. Each of these features has a specific command set: gcloud dns managed-zones create with --visibility=private --networks and --peering-config or --forwarding-config. In the exam, you may be asked to identify the correct parameters to set up a peering zone. For instance, the command would include --peering-network=projects/PROJECT/global/networks/NETWORK and --target-network=projects/PROJECT/global/networks/TARGET_NET. Understanding these details can mean the difference between passing and failing scenario-based questions.

Finally, note that DNS peering is not transitive: if VPC A peers with VPC B, and VPC B peers with VPC C, VPC A does not automatically resolve VPC C's zones. You must set up explicit peering or forwarding between A and C if needed. This limitation is a classic exam trap. Similarly, DNS forwarding does not support load balancing across multiple target servers natively; you must use multiple forwarding zones with different target IPs, or use an external load balancer. Being aware of these edge cases will help you avoid incorrect answers.

## How Cloud DNS Cost Works and Optimizing It for Exams

Cloud DNS has a straightforward pricing model based on two components: the number of managed zones and the number of DNS queries. However, many exam questions will test your understanding of the nuances that affect cost, especially for large-scale deployments. As of the current Google Cloud pricing, each public managed zone costs a fixed monthly fee (approximately $0.20 per month per zone, though this can vary by region or be subject to change). Private zones also incur a cost, but it is typically lower or free for the first few. Queries are charged per million queries. For public zones, the first one million queries per month are free; after that, you pay a rate per million queries (e.g., $0.10 per million). Private zone queries have a similar pricing tier but may have different thresholds.

Why cost matters in exams: you may be asked to choose the most cost-effective architecture for DNS resolution. For example, if you have many internal services that only need to be resolved within a VPC, using a private zone rather than creating a public zone and restricting firewall rules is not only more secure but also cheaper because private zone queries are billed differently. Another common scenario is when an organization has hundreds of domains, each requiring a separate public zone. Since each zone incurs a fixed cost, consolidating domains under a single zone using CNAME or NS delegation might save money, but it also adds management complexity. The exam might ask you to evaluate trade-offs between cost and simplicity.

To reduce costs, you can cache DNS responses aggressively on your clients. Cloud DNS charges per query, but if your application caches results locally, it reduces the number of queries sent to Cloud DNS. Setting a high TTL on records that change infrequently can dramatically cut query volumes. However, be aware that TTL is set per record set, not per zone. In the exam, you might see a scenario where an application is generating millions of DNS queries, causing high costs. The recommended solution is to implement client-side caching and to set appropriate TTLs. You can use Cloud DNS's internal resolution for all Google Cloud APIs and services, which are free and not billed through Cloud DNS pricing. The exam might present a misconfiguration where an application is using an external DNS resolver to reach internal Google APIs, causing unnecessary charges.

Another cost nuance is that DNS queries from Compute Engine instances using the default Google internal DNS resolver (169.254.169.254) are also free. Only queries that hit Cloud DNS directly (especially for public zones) incur charges. This is a key differentiator: when you use --dns-servers=default in your VPC, Cloud DNS is not charged for those queries. But if you configure a custom DNS server policy that points to Cloud DNS explicitly, those queries become billable. The exam often tests this distinction with a question like "Which DNS queries are free?" The answer is that queries to the default metadata server resolver are free, whereas queries that explicitly target Cloud DNS managed zones may be billed.

Large organizations also need to consider Cloud DNS API usage costs, which are separate from query costs. Creating, updating, or deleting managed zones and record sets via the API incurs additional charges, but these are usually negligible compared to query volume. However, in high-churn environments (e.g., automated DNS management for container-based deployments), API costs can add up. The exam may ask about cost optimization for a Kubernetes cluster that frequently updates DNS records. The best practice is to batch changes or use a TTL that reduces the need for rapid updates.

Finally, note that Cloud DNS provides a free tier each month. As of the current offering, the first million queries for public zones are free, and the first private zone per project may also be free. Understanding these limits helps you answer scenario questions about small-scale deployments. For instance, a startup with moderate traffic might not incur any Cloud DNS costs at all. Always check the latest Google Cloud pricing page before the exam, but the core concepts of fixed zone fees plus per-query charges remain stable. When you see a question about DNS costs, think about the two levers: reduce the number of zones and reduce the query volume through caching and careful TTL management.

## Common mistakes

- **Mistake:** Creating a CNAME record for the root domain (example.com) instead of an A record.
  - Why it is wrong: Per RFC standards, a CNAME record cannot exist at the zone apex. The root domain must have an A or AAAA record. Attempting to use a CNAME there will cause resolution failures for the domain.
  - Fix: Use an A (or AAAA for IPv6) record for the root domain, and use CNAME only for subdomains like www.example.com.
- **Mistake:** Forgetting to update the NS records at the domain registrar after creating a DNS zone.
  - Why it is wrong: The domain registrar holds the delegation information. If the NS records still point to the old nameservers, cloud DNS will never receive queries for that domain, and the records you set up will be ignored.
  - Fix: After creating a DNS zone, note the authoritative nameserver addresses provided by the cloud service and update the NS record at the registrar to match.
- **Mistake:** Using a public DNS zone for internal resolution when a private zone is needed.
  - Why it is wrong: A public zone is exposed to the internet. Using it for internal services means your internal IP addresses are publicly visible, which is a security risk. It also means external users could potentially resolve internal hostnames.
  - Fix: Create a private DNS zone and associate it with the VPC or network where the internal services reside. Use private zones for any resolution that should not be public.
- **Mistake:** Setting a very high TTL value before making changes.
  - Why it is wrong: A high TTL (e.g., 86400 seconds) means DNS resolvers will cache records for a full day before checking for updates. If you need to change an IP address quickly, users will still be directed to the old IP until the cache expires.
  - Fix: When planning changes, lower the TTL to 300 seconds (5 minutes) a day before the change, then make the change, and later increase the TTL again for performance.
- **Mistake:** Assuming that cloud DNS automatically resolves all internal hostnames without configuration.
  - Why it is wrong: By default, cloud DNS only resolves records you explicitly create. It does not automatically create records for every VM's hostname or private IP unless you use a default internal DNS service (like AWS provided DNS or Google Cloud's internal DNS).
  - Fix: For automatic VM hostname resolution, use the default internal DNS provided by the cloud platform (e.g., compute.internal in AWS). For custom names, create records in the DNS zone manually or via automation scripts.
- **Mistake:** Using a CNAME record to point to an IP address.
  - Why it is wrong: A CNAME record must point to a domain name, not an IP address. If you try to set a CNAME to 192.168.1.1, the DNS server will reject it as invalid.
  - Fix: Use an A record to point a name to an IPv4 address, and use CNAME records only to point one name to another domain name.

## Exam trap

{"trap":"A question that asks: 'You have configured a CNAME record for www.example.com pointing to example.com, but you also have an A record for example.com. Is this configuration valid?'","why_learners_choose_it":"Learners think that because the CNAME is for the subdomain and the A record is for the root, they can coexist. They also might think that a CNAME can point to a domain that has an A record.","how_to_avoid_it":"Remember that a CNAME record cannot coexist with any other record of the same name. However, the CNAME record for www.example.com does not conflict with the A record for example.com because they are different names. The configuration is valid. The trap is that some learners incorrectly think a CNAME at the apex is the same as a CNAME for a subdomain."}

## Commonly confused with

- **Cloud DNS vs Local DNS cache:** Cloud DNS is an authoritative service that hosts the official records for a domain. A local DNS cache is a temporary storage on a user's device or a resolver that stores previously resolved queries to speed up future lookups. Cloud DNS provides the source of truth; the cache stores answers from that source. (Example: Cloud DNS is like the central library that holds all phone numbers. The local cache is like the sticky note on your desk where you wrote down a number you looked up earlier.)
- **Cloud DNS vs Amazon Route 53:** Route 53 is AWS's managed DNS service, comparable to Google Cloud DNS. The term 'Cloud DNS' is often used generically, but in certification exams, you need to know the specific service of the platform in question. Route 53 offers unique features like health checks, traffic flow, and domain registration. Google Cloud DNS emphasizes integration with GCP services and DNSSEC. (Example: Both are car brands: Route 53 is like Toyota, Cloud DNS (Google) is like Honda. Both get you from point A to point B, but they have different dashboard layouts and options.)
- **Cloud DNS vs Azure DNS:** Azure DNS is the managed DNS service for Microsoft Azure. While functionally similar to Google Cloud DNS and Route 53, Azure DNS is deeply integrated with Azure Active Directory and Private Link. It also supports Alias records similar to Google. The term 'Cloud DNS' is platform-agnostic; Azure DNS is the specific implementation. (Example: Think of Cloud DNS as the general concept of a 'food delivery service.' Azure DNS is DoorDash, Google Cloud DNS is Uber Eats. They all do the same job but have different apps and restaurant partnerships.)
- **Cloud DNS vs DNS resolver (Recursive resolver):** Cloud DNS is an authoritative nameserver, meaning it holds the actual DNS records for a domain. A DNS resolver is the intermediary that receives queries from clients and performs recursion to find the answer. The resolver does not store the records permanently; it asks the authoritative server on behalf of the client. (Example: Cloud DNS is the official record-keeper at city hall that knows everyone's address. The resolver is the person you ask on the street who calls city hall to find the address for you.)
- **Cloud DNS vs Private DNS:** Private DNS is a feature of Cloud DNS that allows DNS resolution within a private network (VPC) without exposure to the internet. It is not a separate service, but a configuration mode. 'Cloud DNS' can mean either public or private zones, while 'Private DNS' specifically refers to the internal resolution capability. (Example: Cloud DNS is like the company's main phone directory. Private DNS is the internal extension list that only employees can see, not the public.)

## Step-by-step breakdown

1. **Register a Domain** — The process starts with purchasing a domain name from a registrar (e.g., GoDaddy, Namecheap) or directly from the cloud provider if they offer domain registration (AWS Route 53, Google Domains). The domain name is the human-readable address you want to use.
2. **Create a Managed Zone** — In the cloud provider's console, you create a public or private hosted zone that will contain all DNS records for the domain. For example, in Google Cloud you create a zone named 'example.com.' The service automatically assigns authoritative name servers to that zone.
3. **Obtain Nameserver Information** — The cloud DNS service provides a list of NS records (nameserver addresses) for the zone. These are typically formatted like ns-cloud-a1.googledomains.com. You will need these to delegate the domain.
4. **Delegate the Domain at the Registrar** — Log in to your domain registrar's management panel and change the NS records for your domain to the nameservers provided by the cloud DNS service. This step tells the global DNS system that your cloud provider is now the authoritative source for the domain's records.
5. **Add Resource Records** — Within the managed zone, you add the actual DNS records. Common records include: A record for IPv4 address, AAAA for IPv6, CNAME for aliases, MX for mail servers, TXT for verification tokens, and SRV for service discovery. Each record has a name (e.g., 'www'), type, TTL, and a value (e.g., '203.0.113.10').
6. **Set TTL Appropriately** — Time to Live (TTL) tells DNS resolvers how long to cache the record. Lower TTL (e.g., 300 seconds) means changes propagate faster but increases query load. Higher TTL (e.g., 86400 seconds) reduces load but delays updates. Choose based on how often you expect to change records.
7. **Test Resolution** — Use command-line tools like nslookup, dig, or host to verify that the domain resolves correctly. For example: 'nslookup www.example.com.' The output should show the correct IP address. Wait for propagation (minutes to 48 hours depending on TTL).
8. **Enable DNSSEC (Optional but Recommended)** — DNSSEC adds cryptographic signatures to DNS records to prevent spoofing and cache poisoning. Enable DNSSEC at the zone level and then add the DS record (provided by the cloud service) to the parent zone (typically done at the registrar). This secures the chain of trust.
9. **Monitor and Maintain** — Regularly check DNS metrics, review logs for errors, and update records as infrastructure changes. Use automation scripts (e.g., Terraform, CloudFormation) to manage zones as code, ensuring consistency across environments.

## Practical mini-lesson

In a real-world cloud environment, Cloud DNS is rarely used in isolation. It is typically part of a larger architecture involving load balancers, auto-scaling groups, and multiple environments (development, staging, production). Let's walk through a practical setup for a microservices application on Google Cloud. 

 You have three microservices: 'auth-service,' 'payment-service,' and 'frontend.' Each runs in a Kubernetes cluster (GKE) behind a Cloud Load Balancer. Instead of using ephemeral IP addresses that change when pods restart, you want stable DNS names. You create a private DNS zone for the domain 'internal.mycompany.com' and associate it with your VPC. You then create A records for each load balancer's internal IP. For example, 'auth-service.internal.mycompany.com' resolves to 10.0.1.5. This allows services to communicate using readable names. 

 For external access, you have a public zone for 'mycompany.com.' You create an A record for 'api.mycompany.com' pointing to the external IP of the frontend load balancer. You also add a CNAME record for 'www.mycompany.com' pointing to the same A record. To handle failover, you set up a health check that probes the load balancer endpoint. If the health check fails for a certain number of failures, you have a secondary record pointing to a backup region. 

 What can go wrong? One common issue is name collision. If you have both a public zone and a private zone with the same domain name, queries from inside the VPC might resolve to the public IP instead of the private IP, causing traffic to leave the VPC and come back, which is inefficient and can cause security issues. To fix this, use a private zone and ensure the VPC's DNS resolution order prioritizes private zones. 

 Professionals should also understand the cost implications. Each DNS query costs a fraction of a cent, but for a high-traffic site with millions of queries per month, costs add up. Using lower TTL values increases query rate, raising costs. Balance between performance and cost. Also, be aware of DNS query logging: you can enable logs to monitor for suspicious queries, such as domain generation algorithm (DGA) traffic from malware. 

 Finally, automate everything. Using tools like Terraform, you can define zones and records in code. For example, a Terraform resource for a Google Cloud DNS A record looks like: resource 'google_dns_record_set' 'frontend' { name = 'frontend.example.com.' type = 'A' ttl = 300 managed_zone = google_dns_managed_zone.example.name rrdatas = ['34.123.45.67'] }. This ensures that DNS changes are version-controlled and repeatable.

## Commands

```
gcloud dns managed-zones create example-zone --dns-name=example.com. --description="Public zone for example.com"
```
Creates a new public managed DNS zone for the domain example.com. Use this when you first set up DNS for a domain you own.

*Exam note: Tests your knowledge of creating zones with correct syntax. The dns-name must end with a dot and match the owned domain.*

```
gcloud dns record-sets create www.example.com --zone=example-zone --type=A --ttl=300 --rrdatas=192.0.2.1
```
Adds an A record mapping www.example.com to IP 192.0.2.1 with a TTL of 300 seconds. Use this to point a subdomain to an IP.

*Exam note: Commonly tested for correct flag usage: --type, --ttl, --rrdatas. The order of arguments matters. Know that --rrdatas can accept multiple IPs.*

```
gcloud dns record-sets update app.example.com --zone=example-zone --type=A --ttl=60 --rrdatas=203.0.113.5
```
Updates an existing A record for app.example.com to a new IP and reduces TTL to 60 seconds. Use this during planned migration to minimize downtime.

*Exam note: Exam scenarios often involve reducing TTL before a change. This command tests the ability to modify record sets without deleting them.*

```
gcloud dns record-sets import --zone=example-zone --zone-file-format --replace-origin-ns records.bind
```
Imports DNS records from a BIND-style zone file into the zone. Use this for bulk migrations from on-premises DNS.

*Exam note: Tests understanding of import vs. manual creation. The --replace-origin-ns flag retains proper NS records; omit it and you may lose delegation.*

```
gcloud dns managed-zones create private-internal-zone --dns-name=internal.company --visibility=private --networks=https://www.googleapis.com/compute/v1/projects/myproject/global/networks/my-vpc
```
Creates a private DNS zone for internal.company, associated with a specific VPC network. Use this for internal service discovery.

*Exam note: The --visibility=private flag and the full network URL are frequently tested. Forgetting the network parameter causes the zone to fail association.*

```
gcloud dns managed-zones create peering-zone --dns-name=shared.internal --visibility=private --peering-config peer-network=projects/producer-project/global/networks/producer-vpc --networks=https://www.googleapis.com/compute/v1/projects/consumer-project/global/networks/consumer-vpc
```
Creates a DNS peering zone that allows a consumer VPC to resolve names from a producer VPC's private zone. Use this for cross-VPC DNS resolution.

*Exam note: Understanding the directional nature of peering is critical. The peering zone is created in the consumer project, not the producer. Misconfiguration is a common exam trap.*

```
gcloud dns managed-zones create forwarding-zone --dns-name=onprem.company --visibility=private --forwarding-config=target-name-servers=[{"ip":"10.0.0.53"}] --networks=list-of-vpcs
```
Creates a DNS forwarding zone that forwards queries for onprem.company to an on-premises DNS server at 10.0.0.53. Use this for hybrid cloud scenarios.

*Exam note: Forwarding configurations require the target IP to be reachable via VPN or interconnect. The JSON format for target-name-servers is often tested in scenario questions.*

## Troubleshooting clues

- **Public zone not resolving on the internet** — symptom: External users cannot reach your domain; nslookup returns NXDOMAIN or SERVFAIL from that domain.. The most likely cause is that the domain is not delegated to Cloud DNS's name servers. You must update the NS records at your domain registrar to point to the Cloud DNS name servers listed in the zone details. (Exam clue: Questions often describe a scenario where a user registers a domain but still gets NXDOMAIN. The solution is to update the registrar's NS records, not to create more zones within Cloud DNS.)
- **Private zone not resolving within VPC** — symptom: Instances in the VPC cannot resolve names from a private zone; they get NXDOMAIN or default public results.. The private zone must be associated with the VPC network. Check the zone's network list. Also ensure that the VPC is not using a custom DNS server policy that bypasses Cloud DNS. (Exam clue: Exam questions may present a scenario where a private zone exists but doesn't resolve. The fix is to verify the zone is attached to the correct VPC. Watch for misconfigured network self-links.)
- **DNS peering not working between VPCs** — symptom: Instances in the consumer VPC cannot resolve names from the producer's private zone; they get no answer.. DNS peering is unidirectional and must be set up in the consumer VPC. Also check that both VPCs are in the same project or have proper VPC peering established. Without network connectivity, peering won't work. (Exam clue: A classic exam trap: the peering zone should be in the consumer project, not the producer. Misplacement is a frequent wrong answer choice.)
- **Record set update not propagating quickly** — symptom: After updating an A record, some clients still get the old IP for a long time.. The TTL value of the old record set determines how long resolvers cache the old data. If TTL was set high (e.g., 86400 seconds), it takes up to 24 hours for cache to expire. Lowering TTL before the change prevents this. (Exam clue: Exam scenarios test the proactive approach: reduce TTL well before the scheduled change, not after. The command to update TTL is part of the solution.)
- **dns record-sets import overwrites all existing records** — symptom: After importing a zone file, previously existing record sets are missing; only the imported ones remain.. By default, import replaces all record sets in the zone. Use the --replace-origin-ns flag to keep the NS records, but other records are overwritten. This is expected behavior, not a bug. (Exam clue: Questions about bulk imports often test that import is destructive. The correct approach is to export current records, merge, and then reimport, or to add records individually.)
- **Cannot delete a managed zone** — symptom: gcloud dns managed-zones delete fails with error indicating the zone is not empty.. A zone must have zero record sets (except the default NS and SOA) before deletion. You must first delete all user-created record sets using gcloud dns record-sets delete for each record. (Exam clue: Know that you cannot delete a zone with existing record sets. The exam may ask for the correct sequence: delete all RRs first, then delete the zone.)
- **DNS forwarding zone returns SERVFAIL** — symptom: Queries for domains that should be forwarded return SERVFAIL or timeout.. The target DNS server is unreachable from the VPC network. Check firewall rules, VPN connectivity, and that the target IP is correct. Also ensure that the forwarding zone is associated with the correct network list. (Exam clue: A common exam scenario: forwarding is configured but fails due to missing firewall rule. The solution is to allow UDP port 53 to the target IP from the VPC.)

## Memory tip

Remember: 'Apex needs an A', the root of any domain must have an A or AAAA record, never a CNAME. Also, 'CNAME, alias, no IP, no friends', a CNAME record cannot point to an IP address and cannot share its name with any other record type.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/cloud-dns