What Is the Difference Between a DNS Zone and a Domain?
People use "domain" and "zone" interchangeably all the time, and for a single small website that is mostly harmless: you own example.com, your DNS provider has a zone called example.com, and the two line up perfectly. The difference starts to matter the moment you delegate a subdomain to another team or provider, run a separate internal view of your names, or try to work out why a record you added "to the domain" is not showing up. Then you need to know which nameservers are actually responsible for a given name, and that is a question about zones, not domains. This article explains both terms precisely, shows how they relate through delegation, and gives you commands to find the zone any name belongs to. For the underlying resolution process, How Does DNS Work? is a good starting point.
What Is a Domain?
In DNS terms, a domain is a node in the DNS name tree plus everything beneath it. example.com is a domain. So is shop.example.com, and so is com. The domain example.com contains example.com itself and every name ending in .example.com, however deep.
Two other meanings get layered on top of that in everyday use:
- A registered domain is the name you buy from a registrar, such as
example.com. It sits directly under a public suffix likecomorco.uk. This is a business and legal concept: who owns the name, when it expires, which registrar manages it. See What Is the Difference Between a Domain Registrar and a DNS Host? - A domain name sometimes just means any single name, such as
www.example.com. Strictly, that is a name rather than a domain, but the terms blur.
The key point is that a domain is about naming. It says nothing about which servers answer for those names.
What Is a Zone?
A zone is a portion of the DNS namespace that is managed as a single unit by one set of authoritative nameservers. It has:
- An apex (the top name, such as
example.com), which holds an SOA record and NS records. - All the names below the apex, except any parts that have been delegated to other nameservers.
A zone is about authority and administration. It is the thing you load onto a nameserver, the thing with a serial number, the thing that gets transferred between primary and secondary servers, and the thing written down in a zone file.
Put briefly: a domain is a branch of the name tree; a zone is the part of that branch that one set of servers is responsible for.
How Delegation Splits Domains into Zones
The boundary between zones is called a zone cut, and it is created by delegation: adding NS records for a subdomain inside the parent zone. Everything below the cut belongs to the child zone. If you are unfamiliar with how NS records do this, read What Is an NS Record, and How Does It Delegate a Domain?
Consider this setup:
; In the example.com zone (hosted at ns1.example-dns.net)
$ORIGIN example.com.
@ IN SOA ns1.example-dns.net. hostmaster.example.com. (
2026100101 7200 900 1209600 300 )
@ IN NS ns1.example-dns.net.
@ IN NS ns2.example-dns.net.
@ IN A 203.0.113.10
www IN A 203.0.113.10
blog IN A 203.0.113.30
; Delegate shop.example.com to the e-commerce platform's nameservers
shop IN NS ns1.example-shop-dns.com.
shop IN NS ns2.example-shop-dns.com.
Here is how domains and zones line up:
| Name | Domain it belongs to | Zone that is authoritative |
|---|---|---|
example.com | example.com | example.com |
www.example.com | example.com | example.com |
blog.example.com | example.com | example.com |
shop.example.com | example.com | shop.example.com |
cart.shop.example.com | example.com (and shop.example.com) | shop.example.com |
The domain example.com includes every name in that table. The zone example.com includes only the first three, plus the delegation NS records for shop. The shop.example.com zone is a separate zone, with its own SOA and its own nameservers, run by someone else. A record for cart.shop.example.com added to the example.com zone would never be served, because resolvers are referred away to the shop platform's servers before they get there.
The same pattern runs all the way up the tree. The root zone delegates com, the com zone delegates example.com, and so on, each level handing authority down to the next.
When a Domain and a Zone Match
For most small sites, every name under example.com lives in one zone with no delegations. Subdomains like www, blog and mail are just records in that single zone. In that case, "the domain" and "the zone" really are the same set of names, and the distinction is academic. As How to Set Up Subdomains in DNS Settings shows, adding a subdomain usually means adding a record, not creating a zone.
When They Differ
Here are the common situations where a domain spans multiple zones, or a zone does not correspond to what you think of as "your domain."
- Delegated subdomains. A team, vendor or platform runs its own zone for
shop.example.comoreu.example.com. - Separate cloud DNS zones. You create a hosted zone for
dev.example.comin a cloud provider so engineers can manage it with infrastructure-as-code, and delegate it from the main zone. - Internal or private zones. A private zone such as
corp.example.comexists only on internal resolvers, or a split view serves different data for the same zone inside your network. See What Is Split-Horizon DNS? - Reverse zones. Zones such as
113.0.203.in-addr.arpahold PTR records for IP ranges. They belong to whoever controls the address block, not to any forward domain. - Zones above a registered domain.
co.ukis a domain and a zone, but nobody registers it as "their domain"; it is a public suffix that delegates to registrants.
How to Find the Zone a Name Belongs To
Because of delegation, you cannot tell from a name alone which zone it lives in. You have to ask DNS. The simplest technique is to query the SOA record for the name: if the name is not itself a zone apex, the authoritative server returns the SOA of its enclosing zone in the authority section.
dig www.example.com SOA +noall +authority
example.com. 300 IN SOA ns1.example-dns.net. hostmaster.example.com. 2026100101 7200 900 1209600 300
The owner of the SOA, example.com., is the zone www.example.com belongs to. Now try a delegated name:
dig cart.shop.example.com SOA +noall +authority
shop.example.com. 3600 IN SOA ns1.example-shop-dns.com. admin.example-shop-dns.com. 2026093001 3600 600 604800 3600
This time the SOA owner is shop.example.com., revealing the zone cut. If you query the apex of a zone directly, the SOA appears in the answer section instead. These are standard dig techniques; How to Use the dig Command for DNS Lookups covers more.
To see the delegation chain explicitly, dig +trace walks from the root down:
dig cart.shop.example.com A +trace
Each block in the output shows a referral from one zone to the next: root to com, com to example.com, example.com to shop.example.com. The last step is the zone that actually answers.
In Python, dnspython has a helper that does the SOA walk for you:
import dns.resolver
for name in ["www.example.com", "cart.shop.example.com"]:
zone = dns.resolver.zone_for_name(name)
print(f"{name} -> zone {zone}")
dns.resolver.zone_for_name queries for SOA records at the name and each parent until it finds one, and returns that zone's name. It is a quick way to audit which zone each of your hostnames depends on.
Why the Distinction Matters in Practice
Where to add records
Records must be added to the zone that is authoritative for the name. If shop.example.com is delegated, a TXT record for _verify.shop.example.com has to be added at the shop platform, not in your main DNS dashboard. This is a frequent cause of "I added the record but verification still fails."
Zone-level settings
DNSSEC signing, zone transfers, SOA timers and serial numbers are all per zone. Enabling DNSSEC on example.com does not sign shop.example.com; that zone's operator must sign it, and you must publish a DS record for it in your zone. See What Is DNSSEC?
Migrations
When you move DNS providers, you migrate zones. A delegated subzone stays where it is unless you move it separately, and its NS records in the parent must be carried across exactly.
Security
Each delegation is a trust relationship. If a delegated zone's nameservers are decommissioned but the NS records remain in your zone, anyone who can claim those nameservers may control that subdomain. Audit delegations as carefully as you audit records.
Quick Comparison
| Aspect | Domain | Zone |
|---|---|---|
| What it is | A branch of the DNS name tree | An administrative unit of DNS data |
| Defined by | Its name | Its SOA and NS records at the apex |
| Boundaries | Includes everything beneath it | Ends at delegations (zone cuts) |
| Managed by | Registrant (for registered domains) | Authoritative nameserver operator |
| Has a serial number | No | Yes, in the SOA |
| Unit of transfer and signing | No | Yes |
DNS Zone vs Domain FAQ
Not exactly. A domain is a branch of the DNS name tree, while a zone is the part of that branch managed by one set of authoritative nameservers. For simple setups without delegations, they cover the same names.
Yes. Any subdomain can be delegated to different nameservers, creating a separate zone. The domain example.com might be split into example.com and shop.example.com zones, for example.
A zone contains its apex domain and every subdomain that has not been delegated away, so in the DNS sense it covers many domains. It cannot contain two unrelated registered domains, though; each needs its own zone.
No. A subdomain is in the parent's zone by default, but if it has been delegated with NS records, it belongs to its own zone.
The apex is the top name of a zone, where its SOA and NS records live. For the example.com zone, the apex is example.com itself.
Query the SOA record for the hostname with dig and look at the owner name of the SOA returned in the authority section. That owner is the enclosing zone.
A zone cut is the boundary between a parent zone and a child zone, created by NS records for the child in the parent zone.
One common reason is that the name is in a delegated zone, so your record was added to a zone that is not authoritative for it. Check the zone with an SOA query and add the record there.
Conclusion
A domain is a name and everything beneath it in the DNS tree. A zone is a slice of that tree that one set of authoritative nameservers manages, starting at an apex with SOA and NS records and ending wherever a subdomain is delegated elsewhere. For a typical site, the two line up exactly, which is why the words are used interchangeably.
The difference becomes essential as soon as delegation enters the picture. It decides where records must be added, which operator controls DNSSEC and SOA timers, what moves during a migration, and where security responsibilities lie. When in doubt, ask DNS: an SOA query or a dig +trace will tell you exactly which zone owns any name.
Here are some useful references for going deeper on zones and domains:
- RFC 1034: Domain Names - Concepts and Facilities — defines the domain name space, zones and delegation.
- RFC 9499: DNS Terminology — the current IETF definitions of domain, zone, apex, zone cut and related terms.
- Cloudflare Learning Center: What is a DNS zone? — a short explainer of zones versus domains.
- dnspython Documentation: dnspython — includes the resolver helpers used above.
- BIND 9 Documentation: BIND 9 Administrator Reference Manual — configuring zones and delegations on an authoritative server.
