A DNS zone is a portion of the DNS namespace administered by a single entity. A DNS record is one entry within a zone. People conflate them constantly — “we updated our DNS record” can mean either a single A record or the entire zone file. The distinction matters when delegating subdomains, managing nameservers, or debugging.

This post explains zones, records, and the delegation chain that connects them.

A Quick Refresher on DNS

DNS is a hierarchical tree:

.                          (root)
├── com
│   ├── example.com         (a zone)
│   │   ├── www              (a record in example.com)
│   │   ├── mail
│   │   └── api
│   └── google.com
├── org
└── net

For more on lookup flow, see how DNS lookup works.

What a Zone Is

A zone is a portion of the namespace where one authority (usually one organization) controls all records.

Example: example.com is a zone. Within that zone are records:

example.com itself — A, MX, etc.
www.example.com — A record.
mail.example.com — A or CNAME record.
api.example.com — A record.

All of these are managed under the example.com zone. The same organization decides what each resolves to.

A zone is the unit of DNS administration. Each zone has a set of authoritative nameservers that serve its records.

What a Record Is

A record is one entry: a name + type + value.

www.example.com.    300   IN   A      203.0.113.5
                   TTL    class type   value

This is one A record for www.example.com. Other records for the same name are independent:

example.com.    3600  IN  A      203.0.113.5
example.com.    3600  IN  MX 10  mail.example.com.
example.com.    3600  IN  NS     ns1.example.com.
example.com.    3600  IN  NS     ns2.example.com.
example.com.    3600  IN  SOA    ns1.example.com. admin.example.com. ...

Multiple records, same zone. For the record types you’ll encounter, see DNS record types reference.

SOA and NS Records

Every zone has two special record types at its apex (root of the zone):

SOA (Start of Authority)

One per zone. Contains:

Primary nameserver name.
Email of the responsible person.
Serial number (incremented on changes).
Refresh, retry, expire, minimum TTL values.

example.com.   IN  SOA  ns1.example.com. hostmaster.example.com. (
    2026052901   ; serial
    7200         ; refresh
    1800         ; retry
    1209600      ; expire
    300          ; minimum
)

The SOA identifies the zone’s authority and configures replication between primary and secondary nameservers.

NS records

List the authoritative nameservers for the zone.

example.com.   IN  NS  ns1.example.com.
example.com.   IN  NS  ns2.example.com.

These tell the world “to find records in example.com, ask these nameservers.”

Delegation

A parent zone delegates a subzone via NS records.

Example: .com zone has NS records for example.com pointing to Example’s nameservers:

example.com.   IN  NS  ns1.example.com.
example.com.   IN  NS  ns2.example.com.

When a resolver queries the .com nameservers about www.example.com, the .com servers return these NS records: “I don’t have www.example.com; ask Example’s nameservers.”

The resolver then queries Example’s nameservers.

This delegation is how the hierarchy works. The root delegates to TLDs (.com, .org); TLDs delegate to second-level domains (example.com); these can further delegate to subdomains.

Subdomain Delegation

You can delegate a subzone within your zone. Two ways:

Same zone (most common)

api.example.com is just a record in example.com. The same nameservers serve both.

api.example.com.  IN  A   203.0.113.10

No new zone; just records in the parent zone.

Separate subzone (delegated)

api.example.com is its own zone, served by different nameservers (maybe AWS, maybe Cloudflare, maybe internal).

In example.com:

api.example.com.   IN  NS  ns1.aws.com.
api.example.com.   IN  NS  ns2.aws.com.

Now queries for api.example.com get delegated to AWS’s nameservers, which have their own zone file for api.example.com.

When to delegate

Different teams manage different services.
Different DNS providers for different services.
Internal vs external DNS for the same subdomain.

Most small/medium organizations don’t bother with subdomain delegation. Everything is records in one zone.

Glue Records

A subtle problem with delegation: what if the nameserver for a subdomain is inside that subdomain?

example.com.    IN  NS  ns1.example.com.
ns1.example.com.  IN  A   203.0.113.1

To find example.com records, you ask ns1.example.com. But to find ns1.example.com, you ask… ns1.example.com. Circular.

Glue records solve this. The parent zone (e.g., .com) includes the A record for ns1.example.com directly:

example.com.        IN  NS  ns1.example.com.
ns1.example.com.    IN  A   203.0.113.1   ← glue

The resolver can resolve ns1.example.com without first having to query example.com itself.

Glue records are usually invisible to users; they’re configured at the registrar / TLD level.

Zone Transfer

Zones replicate from a primary nameserver to one or more secondaries:

AXFR — Full zone transfer. Whole zone copied.
IXFR — Incremental zone transfer. Just the changes since last serial.
NOTIFY — Primary tells secondaries “I have changes; pull them.”

Most modern DNS (cloud-based) handles this transparently. For self-hosted DNS, you configure primary and secondaries explicitly.

Wildcard Records

A record using * matches any name not otherwise defined:

*.example.com.   IN  A   203.0.113.99

Now random.example.com, whatever.example.com, anything not explicitly defined, resolves to 203.0.113.99.

Useful for catch-all subdomain routing. Common in SaaS where customers get customername.app.example.com URLs.

CNAME Constraints

CNAME records have a specific limitation: a name with a CNAME can’t have other records.

www.example.com.   IN  CNAME  example.com.   ✓
www.example.com.   IN  A      203.0.113.5    ✗ (can't coexist with CNAME)

This is why you can’t have a CNAME at the zone apex (example.com itself usually has MX, NS, SOA records, so you can’t make it a CNAME).

Modern providers (Cloudflare, Route 53) sometimes offer “ALIAS” or “ANAME” records — proprietary types that work like CNAMEs but at the apex. Internally they resolve the target dynamically.

Zone Files

Traditional DNS uses zone files — text files in a specific format:

$ORIGIN example.com.
$TTL 3600

@        IN  SOA  ns1.example.com. admin.example.com. (
            2026052901 7200 1800 1209600 300 )

         IN  NS   ns1.example.com.
         IN  NS   ns2.example.com.
         IN  A    203.0.113.5
         IN  MX   10 mail.example.com.

www      IN  A    203.0.113.5
api      IN  A    203.0.113.10
mail     IN  A    203.0.113.20
ftp      IN  CNAME www

@ represents the zone apex. $ORIGIN sets the implicit suffix.

Modern DNS providers (Cloudflare, Route 53) usually present a web UI on top of this. The underlying concepts are the same.

DNS Caching at the Zone Level

Recursive resolvers cache records based on TTL. Different records can have different TTLs:

example.com.       86400 IN  A      203.0.113.5     ← cached for 24 hours
api.example.com.   300   IN  A      203.0.113.10    ← cached for 5 minutes

For planning changes, see DNS caching explained.

Zone-Level Considerations

A few practical zone-level decisions:

TTL strategy

Long TTLs for stable records (the main A record); short TTLs for things that change (load balancer IPs, DDNS).

Sub-delegation

Use it for clearly separate operations (different teams, different providers). Don’t fragment without reason.

Wildcard

Useful for SaaS patterns; risky if you don’t want unknown subdomains to resolve.

Provider

Cloudflare, AWS Route 53, Google Cloud DNS, NS1 are the main providers in 2026. All anycast, all fast, all reliable.

What This Means for Application Developers

For most application developers, the zone vs record distinction is operational — you might never think about it. Where it surfaces:

Buying a domain → you get a zone.
Adding records → you’re modifying the zone.
Subdelegation → you tell the parent zone where your child zone’s nameservers are.
CDN setup → you point a CNAME at the CDN; the CDN’s zone serves the actual IPs.

The Ip2Geo DNS lookup tool queries records within a zone; the broader zone structure is what makes those records resolvable.

TL;DR

Zone = portion of DNS namespace under one authority.
Record = one entry in a zone (name + type + value).
SOA + NS are zone-level metadata.
Delegation via NS records hands subzones to other nameservers.
Glue records break circular dependencies in delegation.
CNAME can’t coexist with other records on the same name.
Wildcards match any name not explicitly defined.
Different TTLs per record are normal.

The zone vs record distinction is one of those bits of DNS vocabulary that’s worth keeping straight. It makes infrastructure conversations clearer (“we’re moving the api subdomain to a different zone” vs “we’re updating an A record”). For DNS basics, see how DNS lookup works; for the specific record types, DNS record types reference.

DNS Zones vs Records: The Hierarchy Explained