What Is a DNS Zone

A DNS zone is a segment of the DNS namespace that contains the records for a specific domain or group of domains. It defines how traffic for that domain is handled and where it should go. Every domain that is resolvable on the internet belongs to at least one DNS zone, and understanding zones is essential to managing DNS effectively.

Zone vs. Domain

These terms are related but distinct. A domain is a name in the DNS hierarchy, like example.com. A zone is the administrative unit that contains the DNS records for that domain. The difference becomes clear with delegation:

• example.com is a domain. Its zone contains records for example.com, www.example.com, mail.example.com, and so on.
• If you delegate blog.example.com to different nameservers, blog.example.com becomes its own zone. The domain example.com still includes blog.example.com in its hierarchy, but the zone for example.com no longer contains the records for blog.example.com.

In short, a domain is a name; a zone is the collection of records managed by a specific set of authoritative nameservers.

How DNS Zones Work

Each zone holds the essential DNS records that guide users to your website, email, and other services. The authoritative DNS server for a zone is responsible for serving these records when queried by recursive resolvers.

When a resolver needs to find the A record for www.example.com, it follows the delegation chain: the root servers point to the .com TLD servers, which point to the authoritative servers for the example.com zone. That zone then provides the answer.

Every zone must contain at least two records:

• An SOA record (Start of Authority) that identifies the primary nameserver, the responsible party, and timing parameters like refresh intervals and TTL minimums
• One or more NS records that identify the authoritative nameservers for the zone

Zone File Format

A zone file is the text representation of a DNS zone. While modern DNS platforms like DNScale store zone data in databases, the zone file format remains the standard way to represent and exchange DNS data. Here is a simplified example:

$ORIGIN example.com.
$TTL 3600
 
@       IN  SOA   ns1.dnscale.eu. admin.example.com. (
                    2024010101  ; Serial
                    7200        ; Refresh
                    3600        ; Retry
                    1209600     ; Expire
                    300         ; Minimum TTL (negative caching)
              )
 
        IN  NS    ns1.dnscale.eu.
        IN  NS    ns2.dnscale.eu.
        IN  A     192.0.2.1
        IN  AAAA  2001:db8::1
        IN  MX    10 mail.example.com.
        IN  TXT   "v=spf1 include:_spf.example.com ~all"
 
www     IN  CNAME example.com.
mail    IN  A     192.0.2.10

Key elements of this format:

• $ORIGIN sets the base domain for relative names in the file
• $TTL sets the default TTL for records that do not specify one
• @ is shorthand for the zone origin (example.com. in this case)
• The trailing dot (.) after domain names indicates a fully qualified domain name (FQDN)
• Records without a trailing dot are relative to the $ORIGIN

You can import zone files into DNScale using the zone import feature.

Types of DNS Zones

Primary Zone

The primary zone (also called the master zone) is the authoritative source of DNS data. All changes to zone records are made on the primary. In DNScale, every zone you create is a primary zone, and changes are replicated across edge nodes automatically.

Secondary Zone

A secondary zone (also called a slave zone) is a read-only copy of a primary zone, used for redundancy and load distribution. Secondary servers periodically fetch zone updates from the primary through zone transfers (AXFR/IXFR). For more on this architecture, see What Is Secondary DNS and Multi-Provider DNS Deployment.

Reverse Zone

A reverse zone maps IP addresses back to domain names using PTR records. Reverse zones use a special naming convention:

• IPv4: 2.0.192.in-addr.arpa for the 192.0.2.0/24 network
• IPv6: Under the ip6.arpa domain

Reverse DNS is important for email deliverability, network diagnostics, and security verification.

Forward Zone

The term forward zone simply refers to a standard zone that maps domain names to IP addresses and other records — the opposite of a reverse zone. Most zones you work with day to day are forward zones.

Zone Delegation

Zone delegation is the mechanism that makes the DNS hierarchy work. When a zone delegates a subdomain, it creates NS records pointing to the nameservers responsible for that subdomain's zone.

For example, if example.com delegates api.example.com:

; In the example.com zone file
api     IN  NS    ns1.api-provider.com.
api     IN  NS    ns2.api-provider.com.

This tells resolvers that api.example.com and everything below it is managed by a different set of nameservers. The example.com zone no longer contains A, AAAA, or other records for api.example.com — it only contains the delegation NS records.

To verify delegation with dig:

# Check which nameservers are authoritative for a domain
dig NS example.com +short
ns1.dnscale.eu.
ns2.dnscale.eu.
 
# Check delegation for a subdomain
dig NS api.example.com +short
ns1.api-provider.com.
ns2.api-provider.com.

For a detailed guide on setting up nameserver delegation with DNScale, see DNS Delegation by Region.

Subzones

A subzone is created whenever a portion of a zone is delegated to different nameservers. The parent zone retains authority over everything except the delegated portion. Common reasons to create subzones include:

• Organizational separation — different teams manage different parts of the DNS namespace
• Geographic distribution — using regional nameservers for specific subdomains
• Service isolation — keeping a high-traffic subdomain on dedicated infrastructure
• Security boundaries — limiting who can modify records for specific subdomains

Querying Zone Data with dig

You can use dig to inspect various aspects of a zone:

# Query the SOA record to see zone metadata
dig SOA example.com
;; ANSWER SECTION:
example.com.  3600  IN  SOA  ns1.dnscale.eu. admin.example.com. 2024010101 7200 3600 1209600 300
 
# List the nameservers for a zone
dig NS example.com
 
# Query a specific record type
dig A example.com
dig AAAA example.com
dig MX example.com
 
# Query a specific nameserver directly
dig example.com @ns1.dnscale.eu
 
# Attempt a zone transfer (will fail against properly secured servers)
dig AXFR example.com @ns1.dnscale.eu

Tip: When troubleshooting DNS issues, always query the authoritative nameserver directly (using @ns1.dnscale.eu) to confirm what the zone actually contains, then compare with what public resolvers return.

Zone Security

Protecting your zone is critical. Several mechanisms help secure zone data:

• DNSSEC signs zone records cryptographically, allowing resolvers to verify that responses have not been tampered with
• CAA records specify which certificate authorities are allowed to issue SSL/TLS certificates for your domain
• SPF, DKIM, and DMARC protect your domain against email spoofing by adding policy records to your zone
• Zone transfer restrictions prevent unauthorized parties from downloading your entire zone file
• Access controls — DNScale supports multi-user accounts so you can limit who can modify zone records

For a broader overview of DNS threats, see DNS Attacks and Threats.

Managing Zones in DNScale

When you create a zone in DNScale, the platform automatically:

1. Creates the SOA record with appropriate timing parameters
2. Adds NS records for the DNScale nameservers in your selected region
3. Generates system records that DNScale manages
4. Replicates the zone to all edge nodes in your region via database replication

You can manage records through the dashboard, the API, Terraform, or DNSControl. For importing existing zones, DNScale supports multiple zone import methods.

After creating a zone, you must update your domain registrar to point to the correct DNScale nameservers for your region. See DNS Delegation by Region for specific instructions.

Conclusion

DNS zones are the organisational framework behind every domain. They define the boundary of administrative control, contain the records that make your services reachable, and enable the delegation hierarchy that makes DNS scalable. By managing your zones carefully through DNScale, you keep records consistent and served across the anycast network.