What is the difference between a domain and a DNS zone?

A domain is a name in the DNS tree together with everything beneath it: example.com as a domain includes www.example.com, mail.example.com, app.dev.example.com and any other name ending in example.com. A DNS zone is the part of that tree that's managed as one administrative unit, with one SOA record and one set of authoritative name servers. For most websites the domain and the zone cover exactly the same names, which is why the terms are often used interchangeably. They separate when part of a domain is delegated: if dev.example.com is handed to different name servers, the example.com domain now spans two zones, example.com and dev.example.com.

The distinction sounds academic, but it explains a lot of practical behaviour: why a subdomain can live at a completely different DNS provider, why some record changes need your registrar and others don't, and why a missing NS record can make a whole branch of your domain disappear. In this article you'll learn what each term means precisely, how delegation creates zone boundaries, how to find out which zone a name belongs to, when splitting a domain into several zones is a good idea, and how to set one up.

What Is a Domain?

In DNS terms, a domain is a node in the namespace tree and the whole subtree below it. The tree starts at the root (.), branches into top-level domains such as com and uk, and continues down:

.                          (root)
└── com                    (top-level domain)
    └── example            (example.com)
        ├── www            (www.example.com)
        ├── mail           (mail.example.com)
        └── dev            (dev.example.com)
            ├── app        (app.dev.example.com)
            └── db         (db.dev.example.com)

Each of these nodes is a domain in its own right. dev.example.com is a domain, and it's also a subdomain of example.com, which is itself a subdomain of com. Domains are about names and hierarchy.

"Domain" in Everyday Use

Outside DNS specifications, people usually mean the registered domain: the name you bought from a registrar, such as example.com or example.co.uk. This is what appears on your invoice and what you renew each year. Everything else below it is yours to create freely without registering anything.

What Is a DNS Zone?

A zone is about administration and data. It's the set of names, and the records attached to them, that are:

• Managed by the same administrator.
• Served by the same authoritative name servers.
• Described by a single SOA record at the top, called the zone apex.
• Stored and transferred as one unit, such as one zone file or one hosted zone at a provider.

A zone starts at its apex and includes every name below it until it reaches a delegation. At a delegation, the parent zone holds only NS records (and glue, if needed) pointing to the child zone's servers. Everything below that point belongs to the child zone. The boundary is called a zone cut.

Side by Side

	Domain	DNS zone
What it describes	A name and everything beneath it in the tree	A portion of the tree managed as one unit
Defined by	The namespace hierarchy	Delegation with NS records
Has an SOA record?	Not necessarily	Exactly one, at the apex
Contains	Subdomains at every level	Records for its own names, plus delegations to child zones
Bought from	A registrar (for registered domains)	Not bought; created at a DNS host or on your own server
Example	example.com includes app.dev.example.com	The example.com zone may stop at dev.example.com

A useful rule of thumb: every zone is a domain, but not every domain is a zone. www.example.com is a domain, but it's almost always just a name inside the example.com zone, not a zone of its own.

Three Common Arrangements

1. One Domain, One Zone

This is the typical small business setup. Every record, from example.com down to staging.api.example.com, lives in a single zone at one DNS provider:

$ORIGIN example.com.
@            IN  SOA   ns1.example.net. hostmaster.example.com. 2026101101 7200 3600 1209600 3600
@            IN  NS    ns1.example.net.
@            IN  NS    ns2.example.net.
@            IN  A     203.0.113.10
www          IN  A     203.0.113.10
dev          IN  A     203.0.113.50
app.dev      IN  A     203.0.113.51

Here app.dev.example.com is a three-level name, but it doesn't need its own zone. Subdomains are simply records in the parent zone unless you deliberately delegate them.

2. One Domain, Several Zones

Now suppose your development team wants to manage everything under dev.example.com themselves, at a different provider. You delegate it by adding NS records in the parent zone and removing the old dev records:

$ORIGIN example.com.
@            IN  SOA   ns1.example.net. hostmaster.example.com. 2026101102 7200 3600 1209600 3600
@            IN  NS    ns1.example.net.
@            IN  NS    ns2.example.net.
@            IN  A     203.0.113.10
www          IN  A     203.0.113.10

; Delegation: everything under dev.example.com now lives in another zone
dev          IN  NS    ns-dev1.example.org.
dev          IN  NS    ns-dev2.example.org.

The child zone, hosted on the other provider, has its own SOA and NS records:

$ORIGIN dev.example.com.
@            IN  SOA   ns-dev1.example.org. platform.example.com. 2026101101 3600 900 1209600 300
@            IN  NS    ns-dev1.example.org.
@            IN  NS    ns-dev2.example.org.
@            IN  A     203.0.113.50
app          IN  A     203.0.113.51
db           IN  A     203.0.113.52

The example.com domain hasn't changed at all: it still includes app.dev.example.com. But it now consists of two zones.

3. One Zone Per Registered Domain, Many Zones Per Server

The relationship also works the other way. A single DNS provider or server hosts many zones, typically one for each domain you own:

• example.com zone
• example.net zone
• example.org zone

These are separate zones even if they contain identical records, because each one has its own apex and SOA. A zone can never cover two unrelated domains, because a zone is always one connected branch of the tree.

Finding Which Zone a Name Belongs To

From the outside you can't see a provider's dashboard, but DNS itself tells you where the zone cuts are. The trick is to ask for an SOA record.

If you ask for the SOA of a name that's just a record inside a larger zone, you get no answer, but the response includes the enclosing zone's SOA in the authority section:

dig www.example.com SOA +noall +answer +authority

example.com.            3600    IN      SOA     ns1.example.net. hostmaster.example.com. 2026101102 7200 3600 1209600 3600

The owner name, example.com., tells you www.example.com lives in the example.com zone.

If you ask about a name that's the apex of its own zone, the SOA comes back in the answer section:

dig dev.example.com SOA +noall +answer +authority

dev.example.com.        300     IN      SOA     ns-dev1.example.org. platform.example.com. 2026101101 3600 900 1209600 300

That confirms dev.example.com is a separate zone with different name servers and timers.

Checking the Delegation at the Parent

To see the zone cut from the parent's point of view, query the parent zone's name server without recursion:

dig @ns1.example.net app.dev.example.com A +norecurse

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; AUTHORITY SECTION:
dev.example.com.        3600    IN      NS      ns-dev1.example.org.
dev.example.com.        3600    IN      NS      ns-dev2.example.org.

The parent's server doesn't answer the question. It returns a referral, with no aa flag, exactly as a TLD server would. That's the zone cut in action.

Doing It in Python

The dnspython library has a helper that walks up a name until it finds the enclosing zone:

import sys

import dns.resolver

for name in sys.argv[1:]:
    print(f"{name:30} -> {dns.resolver.zone_for_name(name)}")

python3 -m pip install dnspython
python3 zone_for.py www.example.com app.dev.example.com www.bbc.co.uk

www.example.com                -> example.com.
app.dev.example.com            -> dev.example.com.
www.bbc.co.uk                  -> bbc.co.uk.

The last example is a good reminder that registered domains and zones don't always line up with the number of labels. bbc.co.uk is a zone delegated from the co.uk zone, which is in turn delegated from uk.

Why Split a Domain Into Multiple Zones?

Delegating a subdomain adds moving parts, so it's worth doing only for a reason. Good reasons include:

• Different teams: A platform team can manage dev.example.com or k8s.example.com without access to production records like MX and the website.
• Different providers: You might keep the main zone at one provider and delegate aws.example.com to Amazon Route 53 so cloud resources can create their own records.
• Automation with limited blast radius: Tools such as Kubernetes ExternalDNS or certificate automation can be given API credentials for a delegated zone only, so a bug can't touch your main records.
• Different policies: A child zone can have its own TTLs, DNSSEC settings or zone transfer rules.
• Scale: Very large organisations split zones so each one stays a manageable size.

Reasons not to delegate include having only a handful of records under the subdomain, or having no one who will maintain the child zone's name servers. A delegation to name servers that no longer answer breaks every name below it.

Setting Up a Delegated Subdomain

Here's how delegating aws.example.com to Route 53 works, while example.com stays at another provider.

Step 1: Create the Child Zone

With the AWS CLI:

aws route53 create-hosted-zone \
  --name aws.example.com \
  --caller-reference "aws-example-$(date +%s)"

The response includes a DelegationSet with four name servers:

{
  "DelegationSet": {
    "NameServers": [
      "ns-1234.awsdns-26.org",
      "ns-567.awsdns-06.net",
      "ns-1890.awsdns-44.co.uk",
      "ns-89.awsdns-11.com"
    ]
  }
}

Step 2: Add NS Records in the Parent Zone

In the example.com zone, at your existing provider, add an NS record for aws pointing to each of those four servers:

aws   3600  IN  NS  ns-1234.awsdns-26.org.
aws   3600  IN  NS  ns-567.awsdns-06.net.
aws   3600  IN  NS  ns-1890.awsdns-44.co.uk.
aws   3600  IN  NS  ns-89.awsdns-11.com.

You don't need your registrar for this. Delegating a subdomain is done entirely in the parent zone; the registrar is only involved for the registered domain itself.

Step 3: Remove Conflicting Records

Delete any existing records for names at or under aws.example.com from the parent zone. Once the delegation exists, resolvers follow the referral and never see them, so leaving them only causes confusion.

Doing It With Terraform

If you manage DNS as code, both sides can live in one configuration. This example uses the AWS and Cloudflare providers (Cloudflare provider version 5 syntax):

resource "aws_route53_zone" "aws_sub" {
  name = "aws.example.com"
}

resource "cloudflare_dns_record" "aws_sub_ns" {
  count   = 4
  zone_id = var.cloudflare_zone_id
  name    = "aws.example.com"
  type    = "NS"
  content = aws_route53_zone.aws_sub.name_servers[count.index]
  ttl     = 3600
}

A fixed count of 4 is used because Route 53 always assigns four name servers, and their names aren't known until the zone is created.

Step 4: Verify

dig aws.example.com SOA +short
dig +trace test.aws.example.com A | tail -n 6

The SOA should now name an awsdns server, and the trace should show the referral from your main provider's servers to Route 53.

Where the Difference Trips People Up

• "I added the record but it doesn't resolve": If the name is under a delegated subdomain, you edited the wrong zone. Records added in the parent below a zone cut are ignored.
• Changing name servers at the registrar vs adding NS records in a zone: The registrar controls delegation of the registered domain from the TLD. Delegating a subdomain is done with NS records in your own zone. Mixing these up is very common.
• CNAME at a delegated name: A delegation point can't also have a CNAME. Either delegate the name or alias it, not both.
• Forgotten delegations: Decommissioning the child zone's provider without removing the parent's NS records leaves a lame delegation, and sometimes a security risk if someone else can claim that zone at the same provider.
• DNSSEC across zones: If the parent zone is signed and you want the child signed too, the parent needs a DS record for the child, just as the TLD has one for your domain.

---

FAQ: Domains and DNS Zones

---

Conclusion

A domain is about names: a node in the DNS tree and everything below it. A zone is about management: the piece of that tree that one administrator controls, with one SOA, one set of name servers and one source of records. For most domains they coincide, but delegation can split a single domain into several zones, each run by a different team or provider.

Knowing which zone a name lives in tells you where to make a change, who controls it and which servers to check when something breaks. A quick dig name SOA reveals the zone boundary, and a +norecurse query to the parent shows the referral that creates it. With those two checks, delegated subdomains stop being mysterious and become a useful tool for organising your DNS.