# Hosted zone

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/hosted-zone

## Quick definition

A hosted zone is a set of DNS records that tell the internet how to find your website or email. It connects your domain name to IP addresses and other services. Think of it as a file folder that keeps all the routing instructions for a specific domain.

## Simple meaning

Imagine you buy a new house and need to get mail delivered. You give people your street address, but the postal service needs to know exactly which mailbox to drop the letter into. In the world of the internet, a hosted zone is like the postal service's master file for your street address. It contains all the instructions that tell internet traffic where to go when someone types your domain name into a browser.

A hosted zone is created when you set up a domain name in a DNS service like Amazon Route 53 or Google Cloud DNS. It holds records such as A records (which map a domain to an IP address), CNAME records (which map a domain to another domain), and MX records (which route email). Without a hosted zone, your domain name would just be a name with no instructions, like a street address with no mailbox. The hosted zone is the place where you store all the rules for routing traffic. It is the central directory that makes your website, email, and other services accessible by name rather than by a long string of numbers.

Every domain that you want to use on the internet needs its own hosted zone. For example, if you own example.com, you would create a hosted zone for example.com. Inside that zone, you add all the individual records that point to your web server, your mail server, and any other services. When someone anywhere in the world tries to visit your site, their computer asks the DNS system for help, and the hosted zone provides the answer. It is a fundamental building block of how the internet stays organized and usable.

## Technical definition

A hosted zone is a collection of DNS resource record sets that are managed together for a specific domain name. In AWS Route 53, a hosted zone is analogous to a zone file in traditional DNS, but it is hosted entirely in the cloud and automatically made highly available. A hosted zone is authoritative for its domain, meaning it is the final source of truth for DNS queries about that domain.

When you create a hosted zone, the DNS service automatically generates four name server (NS) records and a start of authority (SOA) record. The NS records tell the global DNS system which servers are authoritative for your domain. You must update your domain registrar (where you bought the domain) to point to these NS servers. Once that delegation is set, all DNS queries for your domain will be directed to your hosted zone.

Inside the hosted zone, you create record sets. Each record set has a name (like www.example.com), a type (A, AAAA, CNAME, MX, TXT, etc.), a value (like an IP address or another domain), a TTL (time to live), and a routing policy (simple, weighted, latency-based, etc.). The hosted zone supports multiple record sets with the same name and type, a feature known as record set weighting, which is used for load balancing and failover.

Hosted zones can be public or private. Public hosted zones are accessible from the internet and are used for public-facing services. Private hosted zones are associated with one or more Amazon VPCs and are only resolvable within those VPCs. This is critical for internal service discovery and microservices architectures.

Microsoft Azure uses a similar concept called DNS zones, and Google Cloud DNS calls them managed zones. All major cloud providers offer hosted zone functionality as a managed DNS service. The key benefit is that you do not have to run your own DNS servers; the cloud provider handles the infrastructure, replication, and high availability. This makes hosted zones a core component of cloud networking and essential for any IT professional working with cloud infrastructure.

## Real-life example

Think of a hosted zone like the phone book for a large office building. The building has many floors, and each floor has different departments. When someone wants to reach a specific person, they look up the name in the phone book. The phone book tells them the floor number and desk extension. Without the phone book, the caller would just have the building address and no idea where the person actually sits.

In this analogy, the building's address is the domain name (like example.com). The different floors and departments represent the various services: the web server is on floor 2, the email server is on floor 5, and the file server is in the basement. The phone book is the hosted zone. Each entry in the phone book is a DNS record. For instance, an A record is like saying "the CEO sits at desk 1 on floor 2", it directly maps the name to a location. A CNAME record is like saying "just ask the person at the front desk", it redirects the caller to another name.

The phone book is maintained by the building management, just as the cloud provider maintains the hosted zone. If a department moves to a different floor, the phone book gets updated. Similarly, if you move your website to a new server with a different IP address, you update the DNS record in the hosted zone. The phone book is the single source of truth for where to find people, just as the hosted zone is the authoritative source for your domain's traffic routing. Understanding this analogy helps IT learners grasp that a hosted zone is not the domain itself, but the organized collection of instructions that makes the domain usable.

## Why it matters

Hosted zones are critical because they are the backbone of how the internet translates human-readable domain names into machine-readable IP addresses. Without hosted zones, every user would need to remember numeric IP addresses for every website they visit, which is impractical. For IT professionals, managing hosted zones directly impacts the availability, performance, and security of online services.

In real IT environments, a misconfigured hosted zone can cause website downtime, email delivery failures, and security vulnerabilities. For example, if you accidentally delete the MX record in your hosted zone, email sent to your domain will bounce. If you set the wrong TTL value, DNS changes take longer to propagate, leading to inconsistent user experiences during migrations. Hosted zones also play a role in disaster recovery. By using failover routing policies, you can automatically redirect traffic to a backup site if your primary server goes down.

Cloud architects design hosted zones to handle high query volumes, integrate with load balancers, and support advanced routing like geolocation or latency-based routing. For a company running a global e-commerce platform, a well-designed hosted zone ensures that users in Europe are directed to the nearest server, reducing page load times. In security, hosted zones are used to implement DNSSEC (DNS Security Extensions) to prevent DNS spoofing and man-in-the-middle attacks. They also support TXT records for domain verification and email authentication (SPF, DKIM, DMARC).

For learners studying for IT certifications, understanding hosted zones is not optional. It is a foundational concept in networking, cloud computing, and cybersecurity. Any role from help desk to cloud architect will involve working with DNS records in a hosted zone. Mastering this concept helps you troubleshoot connectivity issues, plan migrations, and secure your organization's online presence.

## Why it matters in exams

In general IT certification exams, DNS concepts including hosted zones appear frequently. For the AWS Certified Solutions Architect Associate exam, hosted zones are a core objective under the networking and content delivery domain. You will see questions about creating public vs private hosted zones, associating private hosted zones with VPCs, and configuring routing policies. The exam expects you to know how to delegate a domain to Route 53 by updating NS records at the registrar.

For the CompTIA Network+ exam, DNS is a major topic, and understanding zone files and record types is essential. While the exam does not use the term 'hosted zone' directly, it covers the same concept under 'DNS zones' and 'zone files.' Questions may ask you to identify the correct record type for a given scenario, such as using an A record for an IPv4 address or an MX record for mail exchange.

In the Microsoft Azure Administrator exam (AZ-104), Azure DNS zones are covered. You need to understand how to create and manage DNS zones, delegate domains, and configure record sets. The exam scenario might involve setting up a custom domain for an Azure web app, which requires creating a DNS zone and adding appropriate records.

The Google Cloud Associate Cloud Engineer exam includes Cloud DNS, where managed zones (hosted zones) are a key concept. Questions test your ability to create a managed zone, add record sets, and configure DNS peering for hybrid cloud environments.

For all these exams, the trick is not just memorizing definitions but applying the concept in scenarios. You might be asked to design a solution for high availability using DNS failover, or to troubleshoot why a new website is not resolving. The exam will test your understanding of how hosted zones interact with registrars, TTL values, and record propagation. Expect multiple-choice questions, scenario-based questions, and in the case of AWS, drag-and-drop exercises for Route 53 configurations.

## How it appears in exam questions

In certification exams, hosted zone questions often fall into three categories: scenario-based design, configuration steps, and troubleshooting.

Scenario-based design questions present a business requirement and ask you to choose the best DNS configuration. For example: A company wants to host its website on two EC2 instances in different regions for high availability. Which Route 53 routing policy should be configured in the hosted zone? The answer is a failover routing policy with primary and secondary records. Another example: A company needs internal DNS resolution for services within a VPC without exposing them to the internet. The answer is to create a private hosted zone and associate it with the VPC.

Configuration step questions test your knowledge of the exact sequence of actions. For instance: What is the first step after creating a public hosted zone in Route 53? The answer is to update the domain registrar's NS records with the four name servers provided by Route 53. Another question might ask: When adding a CNAME record for www to point to the root domain, what is the correct value? The value should be the root domain name, not an IP address.

Troubleshooting questions present a symptom and ask for the likely cause. For example: Users report that email sent to the company domain is not being received. The IT team checks the hosted zone and finds an MX record with the wrong priority. The question asks what needs to be fixed. Another troubleshooting scenario: After migrating a website to a new server, some users still see the old site. The correct answer is that the TTL on the A record in the hosted zone has not expired yet, and the user's DNS resolver still has the old cached value.

Some exams include multiple-response questions where you must select all correct statements about hosted zones. For example, which of the following are true about private hosted zones? Correct answers include: they are only resolvable within associated VPCs, they support the same record types as public zones, and they can be shared across accounts using RAM (Resource Access Manager).

Exam questions may also ask about limits, such as the maximum number of hosted zones per AWS account (default 50, but can be increased). For Azure, questions might ask about the maximum number of record sets per zone (currently 10,000 for public zones).

## Example scenario

You work as a junior cloud administrator for a small e-commerce company called "ShopEasy." The company recently moved its website from a traditional hosting provider to AWS. The domain name is shopeasy.com. Your manager asks you to set up DNS so that customers can reach the website and employees can receive email.

First, you create a public hosted zone for shopeasy.com in Route 53. The service generates four name server addresses. You log in to the domain registrar's website and update the NS records for shopeasy.com to match those four addresses. This step delegates authority for the domain to Route 53.

Next, you need to add records. The website is hosted on an EC2 instance with an elastic IP address of 203.0.113.10. You create an A record with name "shopeasy.com" (the root domain), type A, and value 203.0.113.10. You also want www.shopeasy.com to work, so you create a CNAME record for www that points to shopeasy.com.

For email, the company uses a third-party email service with servers at mail.shopeasymail.com. You create an MX record with priority 10 and value mail.shopeasymail.com. You also add a TXT record with the SPF value that the email provider gave you, to prevent spam filters from rejecting company emails.

After creating the records, you test the setup by using the nslookup command. You check that shopeasy.com resolves to 203.0.113.10 and that the MX record returns the correct mail server. Everything works. Now, customers can type shopeasy.com and reach the website, and employees can send and receive email. This scenario shows the practical steps of using a hosted zone to make a domain functional on the internet.

## Common mistakes

- **Mistake:** Creating a hosted zone but forgetting to delegate the domain at the registrar.
  - Why it is wrong: Without delegation, DNS queries for your domain are still sent to the previous name servers, not to your hosted zone. Your records will never be used, and the domain will not resolve to your services.
  - Fix: After creating the hosted zone, copy the four NS records from the zone and paste them into the domain registrar's name server settings. This tells the global DNS where to find your authoritative zone.
- **Mistake:** Using a CNAME record for the root domain (apex domain) like example.com.
  - Why it is wrong: DNS standards do not allow CNAME records at the zone apex. A CNAME can only be used for subdomains. If you try to create a CNAME for the root, the DNS service will reject it or cause unexpected behavior.
  - Fix: For the root domain, use an A record (for IPv4) or an AAAA record (for IPv6) to point directly to an IP address. If you need to point to an AWS resource like an ALB, use an Alias record instead of a CNAME.
- **Mistake:** Setting the TTL too high when planning a migration.
  - Why it is wrong: A high TTL (like 86400 seconds or 24 hours) means DNS resolvers will cache the old records for a long time. During a migration, users will still see the old IP address for up to 24 hours, causing downtime.
  - Fix: Before a planned migration, lower the TTL to a low value (like 60 or 300 seconds) for the records you plan to change. This ensures changes propagate quickly. After the migration is complete, you can raise the TTL again.
- **Mistake:** Assuming a private hosted zone can be accessed from the internet.
  - Why it is wrong: A private hosted zone is specifically associated with one or more VPCs and is not accessible from the public internet. If you add a record to a private hosted zone, only resources inside the associated VPCs can resolve that name.
  - Fix: If you need a domain to be resolvable from the internet, create a public hosted zone. Use private hosted zones only for internal service discovery, such as resolving internal load balancers or databases by name within your VPC.

## Exam trap

{"trap":"The exam might present a scenario where a company creates a public hosted zone and adds all necessary records, but the website still does not resolve. The options include: update the NS records at the registrar, create a new hosted zone, enable DNSSEC, or add an SOA record.","why_learners_choose_it":"Many learners think that adding records to the hosted zone is sufficient, or they believe the hosted zone is automatically active. They may choose the option to create a new hosted zone because they think the current one is broken.","how_to_avoid_it":"Always remember that creating the hosted zone and adding records is only half the work. The domain registrar must be configured to point to the name servers of the hosted zone. Without delegation, the hosted zone is orphaned and unreachable. The correct first troubleshooting step is to verify the NS delegation at the registrar."}

## Commonly confused with

- **Hosted zone vs DNS Zone:** A DNS zone is a broader concept that includes both hosted zones and traditional zone files. A hosted zone is a specific implementation of a DNS zone provided by a cloud DNS service like AWS Route 53. Traditional DNS zones are often managed on an on-premises DNS server. The difference is in the management model: hosted zones are fully managed by the cloud provider, while traditional zones require you to manage the server. (Example: If you run your own BIND server, you have a zone file. If you use Route 53, you have a hosted zone. The functionality is similar, but the operational overhead is different.)
- **Hosted zone vs Domain Registration:** Domain registration is the process of buying a domain name from a registrar like GoDaddy or Namecheap. A hosted zone is the DNS management container for that domain. Many people confuse the two because some registrars also offer DNS hosting. But you can register a domain with one company and host its DNS elsewhere. The hosted zone does not include ownership of the domain; it only provides the routing instructions. (Example: Registering example.com is like buying a plot of land. Creating a hosted zone is like building the house and setting up the mailbox. You need both, but they are different steps.)
- **Hosted zone vs Record Set:** A record set is an individual DNS record within a hosted zone, such as an A record or MX record. The hosted zone is the container that holds all record sets for a domain. Confusing the two is like confusing a folder with the files inside it. You manage record sets within the hosted zone. (Example: A hosted zone is like a binder. Each record set is a page inside the binder with a specific instruction. You can have many pages in one binder.)

## Step-by-step breakdown

1. **Create the Hosted Zone** — In your cloud DNS service (AWS Route 53, Azure DNS, Google Cloud DNS), you create a new hosted zone for your domain. You specify the domain name, such as example.com, and choose whether it is public or private. The service then automatically generates four name server records and an SOA record for the zone. These are the authoritative servers that will answer DNS queries.
2. **Delegate the Domain** — You must update the name server settings at your domain registrar. You copy the four NS records from the hosted zone and replace the registrar's current NS records with them. This step tells the global DNS system that your hosted zone is now the authority for that domain. Without delegation, no one will query your hosted zone.
3. **Add DNS Records** — Inside the hosted zone, you create the record sets you need. Common records include A records for IPv4, AAAA for IPv6, CNAME for aliasing subdomains, MX for email routing, TXT for verification and email authentication, and SRV for specific service locations. Each record has a name, type, value, TTL, and optionally a routing policy.
4. **Configure Routing Policy (Optional)** — If you need advanced traffic management, you can set a routing policy on A or AAAA records. Simple routing just returns a single value. Weighted routing distributes traffic across multiple records. Latency-based routing sends users to the region with the lowest latency. Failover routing directs traffic to a secondary record if the primary is unhealthy. Geolocation routing sends users based on their geographic location.
5. **Test and Verify** — Use DNS tools like nslookup, dig, or the cloud provider's diagnostic tools to verify that your records resolve correctly. Check that the NS records are propagated by querying the public DNS. Test from different geographic locations to ensure routing policies work as expected. Also, verify that private hosted zones are resolving correctly from within associated VPCs.
6. **Monitor and Maintain** — Regularly check the health of your DNS records. Use cloud provider monitoring to detect query failures or high latency. Keep TTL values appropriate for your change frequency. Review logs for any unauthorized changes. Update records as your infrastructure changes, such as moving to a new server or adding new services.

## Practical mini-lesson

A hosted zone is your central control panel for domain traffic routing. In practice, every time you deploy a new web application, set up email, or migrate infrastructure, you will interact with a hosted zone. Understanding how to create, delegate, and manage hosted zones is a hands-on skill that separates entry-level IT staff from experienced professionals.

Let's walk through a real configuration. Suppose you are using AWS Route 53. You log into the console, go to Hosted Zones, and click Create Hosted Zone. Enter your domain name, choose Public Zone, and create it. Immediately, you see four NS records and one SOA. Copy the NS records. Then go to your domain registrar's website, find the DNS management section, and paste those NS servers. It can take up to 48 hours for delegation to propagate globally, but often it completes in minutes.

Now, you need to point your domain to a web server. If you have a static IP, you create an A record. But modern cloud deployments often use load balancers. For an Application Load Balancer, you do not use a CNAME for the root domain because DNS does not allow it at the apex. Instead, you use an Alias record, which is a Route 53-specific feature that works like a CNAME but can be used at the zone apex. You select the alias target as the load balancer DNS name. This is a common configuration question in exams.

What can go wrong? One common issue is that after creating the hosted zone and adding records, the domain still does not work because the registrar's NS records were not updated. Another problem is that you might accidentally create a private hosted zone when you need a public one, and then external users cannot resolve the domain. Or you might set an incorrect TTL, causing slow propagation and user frustration during a change.

Professionals also use hosted zones for split-brain DNS, the same domain resolves differently internally and externally. For example, internal users see a private IP for the company website, while external users see the public IP. This is achieved by using a private hosted zone for internal VPC resolution and a public hosted zone for external resolution, with the same domain name. Understanding this pattern is essential for enterprise networking.

Finally, always back up your hosted zone records. In Route 53, you can export the zone file. In Azure and Google Cloud, you can export DNS records. If you accidentally delete the hosted zone, you lose all records and must recreate them. Backups and version control prevent disaster.

## Memory tip

Think of a hosted zone as the 'phone book' for your domain, it contains all the numbers (records) that people need to reach your services.

## FAQ

**Can I have multiple hosted zones for the same domain?**

Yes, you can have one public and one private hosted zone for the same domain. This allows different DNS resolution depending on whether the query comes from the internet or from within a VPC. However, you cannot have two public hosted zones for the same domain, as it would create conflicts.

**What is the difference between a public and a private hosted zone?**

A public hosted zone is accessible from the internet and is used to route traffic for public-facing services. A private hosted zone is associated with one or more VPCs and is only resolvable within those VPCs, making it ideal for internal service discovery.

**How long does it take for DNS changes to propagate?**

DNS propagation time depends on the TTL value of the record and the caching behavior of DNS resolvers. If you set a low TTL (like 60 seconds), changes can propagate within minutes. However, if you change the name server delegation at the registrar, it can take up to 48 hours for global propagation.

**Do I need a hosted zone for each subdomain?**

No, you can manage all subdomain records within the same hosted zone for the parent domain. For example, records for mail.example.com and www.example.com can both live in the hosted zone for example.com. You only need a separate hosted zone if you delegate authority for a subdomain to another DNS service.

**Can I migrate a hosted zone from one cloud provider to another?**

Yes, you can export the DNS records from the current provider and import them into the new provider's hosted zone. You then update the domain registrar to point to the new hosted zone's name servers. The migration may experience brief downtime during delegation switchover.

**What is an Alias record and how is it different from a CNAME?**

An Alias record is a Route 53-specific feature that works like a CNAME but can be used at the zone apex (root domain). It also allows you to point to AWS resources like CloudFront distributions and load balancers. A CNAME cannot be used at the zone apex and can only point to another domain name.

**Is a hosted zone the same as a domain?**

No, a domain is the name you register, like example.com. A hosted zone is the DNS container that holds the routing records for that domain. You can register a domain without a hosted zone, but it will not route traffic to your services.

## Summary

A hosted zone is a fundamental DNS concept that every IT professional must understand. It is the container that holds all the routing records for a domain name, acting as the authoritative source for DNS queries. Without a hosted zone, a domain name is just a name with no way to direct traffic to websites, email servers, or other services.

Understanding hosted zones is critical for cloud computing because all major cloud providers offer managed DNS services through hosted zones. Whether you are using AWS Route 53, Azure DNS, or Google Cloud DNS, the principles are the same. You create the zone, delegate the domain, add records, and optionally configure advanced routing policies. Mistakes like failing to delegate the domain or using a CNAME at the zone apex can cause significant downtime.

For certification exams, expect questions that test your ability to apply this knowledge in scenarios. You will need to know when to use public vs private zones, how to set up failover routing, and how to troubleshoot resolution issues. The exam trap to watch out for is assuming that creating the hosted zone is enough, always remember the delegation step.

In professional practice, hosted zones are part of your daily toolkit. They enable high availability, global performance optimization, and secure internal service discovery. By mastering hosted zones, you build a strong foundation in DNS and cloud networking that will serve you throughout your IT career.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/hosted-zone