DNS Records & Concepts
What is a DNS zone?
A DNS zone is a distinct portion of the DNS namespace that is managed as a single administrative unit by a specific authoritative nameserver or set of nameservers. It is the container that holds all the DNS records for a domain, the A records, CNAME records, MX records, TXT records, NS records, and all other record types that define how the domain functions.
The word zone reflects the concept of administrative boundaries within the DNS namespace. The global DNS system is a distributed hierarchy, a tree of domain names that extends from the root down through top-level domains, second-level domains, and subdomains. A zone is a slice of that tree that one organisation or DNS provider takes responsibility for. The organisation controls the zone, creating, updating, and deleting records within it, through their authoritative nameservers.
Every registered domain has at least one DNS zone. example.com is a zone. blog.example.com can be a separate zone if DNS authority for the subdomain is delegated to different nameservers. The root of the DNS namespace, represented as .: is itself a zone managed by IANA. Each TLD, .com, .net, .org: is a zone managed by its registry. The layered structure of zones creates the distributed, delegated architecture that makes the global DNS system function.
How a DNS zone works
A DNS zone is defined by its zone file, a text file that contains all the DNS records for the zone in a standardised format. The zone file is stored on authoritative nameservers and served in response to DNS queries for records within the zone.
Every zone file begins with an SOA record: Start of Authority, that identifies the primary authoritative nameserver for the zone, the administrator contact, and timing parameters that govern zone transfers and caching. The SOA record marks the beginning of the zone and establishes its administrative identity.
The zone file also contains NS records that specify which nameservers are authoritative for the zone. These NS records at the zone apex match the delegation records stored at the parent zone, the TLD nameservers for a second-level domain like example.com, or the domain’s own nameservers for a subdomain zone delegation.
Beyond the SOA and NS records the zone file contains all the operational DNS records, the A records that map hostnames to IP addresses, CNAME records that create aliases, MX records that route email, TXT records for verification and authentication, and any other record types the zone requires.
A simplified zone file for example.com might contain:
The @ symbol represents the zone origin, example.com itself. Each record defines a hostname within the zone and its associated data.
Zone vs domain
The terms zone and domain are related but not identical. Understanding the distinction clarifies how DNS authority is structured.
A domain is a name in the DNS namespace, example.com, blog.example.com, shop.example.com. Domains exist in a hierarchy, example.com is the parent of blog.example.com and shop.example.com.
A zone is an administrative unit that holds DNS records. A single zone typically covers a domain and all its subdomains unless subdomain zones are separately delegated. The example.com zone contains records for example.com, www.example.com, blog.example.com, mail.example.com, and any other subdomain that has not been delegated to a separate zone.
One domain can span multiple zones if subdomain authority is delegated. example.com is managed in one zone. shop.example.com might be delegated to a separate zone managed by a different team or DNS provider. The shop.example.com zone handles all records for that subdomain independently of the parent zone.
The boundary between zones is defined by NS record delegation. When NS records for a subdomain appear in a parent zone they indicate that the subdomain has its own zone managed by the specified nameservers. Everything below the delegation point is in the subdomain zone. Everything above it remains in the parent zone.
Zone delegation and subdomain zones
Zone delegation is the mechanism by which DNS authority for a portion of the namespace is transferred from a parent zone to a child zone. It is the foundation of the DNS hierarchy, how authority flows from the root zone down through TLDs to individual domains and subdomains.
When example.com is registered the TLD registry, which manages the .com zone, adds NS records to the .com zone pointing to the nameservers that will be authoritative for example.com. This is delegation, the .com zone delegates authority for example.com and everything below it to the specified nameservers.
The domain owner can further delegate subdomains. Adding NS records for shop.example.com in the example.com zone delegates authority for the shop subdomain to a different set of nameservers. The example.com zone no longer answers queries for records within shop.example.com: those queries go to the delegated nameservers instead.
Subdomain delegation is used in several common scenarios relevant to redirect management.
Separate teams managing different subdomains: a large organisation might delegate api.example.com to a DNS zone managed by the engineering team and shop.example.com to a zone managed by the e-commerce platform. Each team controls their subdomain independently.
Different DNS providers for different subdomains: connecting shop.example.com to a hosted e-commerce platform that manages its own DNS by delegating the subdomain to the platform’s nameservers.
Microservices and infrastructure organisation: organisations with complex infrastructure use subdomain zone delegation to allow different infrastructure teams to manage DNS for their respective services without requiring access to the parent zone.
DNS zones and authoritative nameservers
Every DNS zone is served by authoritative nameservers, the servers that hold the definitive, current records for the zone and answer queries for those records. Authoritative nameservers are distinct from DNS resolvers: resolvers perform lookups on behalf of clients and may serve cached results, while authoritative nameservers always serve the current zone data.
A zone typically has multiple authoritative nameservers for redundancy, at least two, often more. All authoritative nameservers for a zone must serve consistent data. In traditional DNS architectures one server is the primary, where changes are made, and others are secondaries that receive zone data through zone transfers. In modern managed DNS environments all nameservers are typically peers that receive updates simultaneously through proprietary synchronisation systems.
The NS records in a zone and the corresponding delegation records at the parent zone both specify the same set of authoritative nameservers. Consistency between the zone’s own NS records and the parent delegation is essential, resolvers follow the parent delegation to find the authoritative nameservers and expect to find the zone’s NS records matching when they query those servers.
Zone transfers
A zone transfer is the process by which the complete contents of a DNS zone are copied from one nameserver to another. Zone transfers are the traditional mechanism for keeping secondary nameservers synchronised with the primary.
When a secondary nameserver detects, through the SOA record serial number comparison during its scheduled refresh, that the primary has updated zone data it initiates a zone transfer. The primary sends the updated records to the secondary. The secondary updates its local copy of the zone and begins serving the new data.
Two zone transfer types exist, full and incremental.
AXFR, Authoritative Zone Transfer: transfers the complete zone file from primary to secondary. Every record in the zone is included regardless of whether it changed. Simple to implement but inefficient for large zones where only a small number of records changed.
IXFR, Incremental Zone Transfer: transfers only the records that changed since the last successful transfer. The secondary specifies the serial number of its current zone copy. The primary sends only the differences, records added, deleted, or modified since that serial number. More efficient than AXFR for large zones with frequent small changes.
Modern managed DNS providers typically do not use traditional zone transfers, they use proprietary internal synchronisation that pushes changes to all nameservers simultaneously when records are updated. Zone transfers remain relevant for organisations running their own BIND or other open-source DNS nameserver infrastructure.
Zone transfer security: unrestricted zone transfers expose all DNS records for a zone to anyone who can query the nameserver, a reconnaissance risk in security-sensitive environments. Production nameservers should restrict zone transfers to specific IP addresses, the IP addresses of authorised secondary nameservers only. The allow-transfer directive in BIND and equivalent settings in other DNS software restrict zone transfer access.
DNS zones in managed DNS providers
For domain owners using managed DNS providers, Cloudflare, Route 53, Google Cloud DNS, NS1, and others, the concept of a DNS zone is presented through the provider’s management interface as a collection of DNS records for a domain.
When a new domain is added to a managed DNS provider the provider creates a DNS zone for the domain and populates it with default records. The provider’s nameservers become the authoritative nameservers for the zone. The domain owner updates records through the provider’s control panel or API, the provider handles the underlying zone file management, zone transfers between their nameservers, and all other operational details.
From the domain owner’s perspective the DNS zone is simply the list of DNS records for their domain, add a record, delete a record, change a record value. The zone file format, SOA record management, zone transfer configuration, and nameserver synchronisation are all abstracted away by the managed DNS provider.
Different managed DNS providers store zone data and serve it differently. Cloudflare uses its anycast network to serve DNS responses from locations worldwide. Route 53 uses a similar anycast approach across AWS infrastructure. Some providers support importing and exporting zone files in the standard BIND zone file format, useful for migrating zones between providers without recreating records manually.
DNS zones and redirect management
DNS zones interact with redirect management in several important ways.
Zone records enable redirect infrastructure connection: connecting a domain to redirect management infrastructure requires adding or updating records in the domain’s DNS zone. Adding a CNAME record for www.example.com pointing to redirect infrastructure, adding an A record for the root domain, or adding TXT records for domain verification, all of these are zone-level changes. Access to the DNS zone through the provider’s management interface is a prerequisite for connecting a domain to redirect management.
Zone delegation for redirect subdomains: in complex infrastructure setups a subdomain might be delegated to a redirect management provider’s own nameservers. The redirect provider manages a DNS zone for the subdomain, handling DNS, SSL, and redirect rules for everything under that subdomain, while the parent domain’s zone remains under the domain owner’s control. This allows the redirect provider to make DNS changes within the subdomain zone without requiring access to the parent zone.
Zone export for migration planning: when migrating DNS, changing nameservers to a new provider as part of a redirect management setup, exporting the current zone in zone file format provides a complete record of all DNS records that must be recreated at the new provider. A zone file export captures every record type including obscure ones like SRV records and CAA records that might be overlooked in a manual recreation process.
NS record changes transfer zone authority: changing nameservers by updating NS records at the domain registrar transfers authority for the entire zone, all DNS records for the domain, to the new nameservers. The new DNS provider’s zone must be fully populated with all required records before the NS records are changed. After the NS change the old provider’s zone is no longer consulted for DNS queries.
Zone file format
The DNS zone file format is a standardised text format defined in RFC 1035 that most DNS software understands. While managed DNS providers present zone data through graphical interfaces they typically support importing and exporting in zone file format for interoperability.
Zone file conventions include:
$ORIGIN directive: sets the default domain suffix appended to unqualified names in the file. $ORIGIN example.com. means a record named www is expanded to www.example.com.
$TTL directive: sets the default TTL for records that do not specify their own TTL. Records that need a different TTL include it explicitly.
Fully qualified domain names: names in zone files that end with a trailing dot are fully qualified, they are complete domain names. Names without a trailing dot are relative to the $ORIGIN. www.example.com. is fully qualified. www is relative to the origin and expands to www.example.com.
Comment syntax: semicolons begin comments. Everything after a semicolon on a line is ignored. Comments are used to document records, noting when a record was added, what service it supports, or what the TTL was chosen for.
Checking zone contents
The contents of a DNS zone can be inspected through several mechanisms depending on the zone configuration and what access is available.
Zone transfer query: if the nameserver allows zone transfers a DNS query for the complete zone can retrieve all records:
Most production nameservers restrict zone transfers making this unavailable from arbitrary IP addresses. This is a security best practice, unrestricted zone transfers expose all zone data.
Individual record queries: querying for specific record types reveals the contents of the zone incrementally:
DNS provider management interface: the most reliable way to view all records in a zone is through the DNS provider’s control panel or API. All records are visible and manageable through the interface regardless of transfer restrictions.
Zone export: most managed DNS providers support exporting the zone as a zone file. The export includes all records in a portable format that can be imported to another provider. Useful for auditing zone contents and for migration planning.