This chapter covers DNS zones and zone transfers, a critical topic for the N10-009 exam under Network Implementation (Objective 2.5). DNS zones are administrative partitions of the DNS namespace, and zone transfers are the mechanisms by which DNS servers synchronize zone data. Expect 2-3 exam questions on zone types, transfer mechanisms, and security considerations. Mastery of this topic is essential for understanding how DNS operates in enterprise networks, including Active Directory integration and public DNS hosting.
Jump to a section
Imagine a large public library system with a main branch and several smaller branches. Each branch has its own card catalog (DNS zone) listing books (DNS records) available at that branch. The main branch maintains a master catalog (primary zone) where all changes are made—new books added, old books removed, or books moved to different shelves. To keep the branches consistent, the main branch periodically sends out updated catalog pages (zone transfers) to the smaller branches. A full catalog update (AXFR) is like sending the entire card catalog to a branch that just opened or had its catalog destroyed. An incremental update (IXFR) is like sending only the pages that changed since the last update. Each branch has a serial number on its catalog; when the main branch updates its catalog, it increments its serial number. The branches check the serial number regularly (refresh interval) and request an update if the main branch's serial is higher. If the main branch doesn't respond, the branches retry after a delay (retry interval). If the main branch is unreachable for a long time, the branches can still serve their existing catalog for a limited time (expire interval) before they stop trusting it. This ensures all branches have consistent, up-to-date information while minimizing the amount of data transferred.
What Are DNS Zones?
A DNS zone is a contiguous portion of the DNS namespace that is managed by a specific entity, such as an organization or an administrator. Zones allow delegation of authority—one DNS server can be authoritative for a zone while another handles a subdomain. For example, the domain example.com may have a zone containing all records for example.com, while sub.example.com is delegated to another zone.
Zones are stored in zone files (on BIND) or in Active Directory (on Microsoft DNS). Each zone has a SOA (Start of Authority) record that defines the primary name server, the responsible person's email, and timers for zone transfer behavior. The SOA record is critical for zone transfers.
Types of Zones
Primary Zone: The read-write copy of the zone. All changes (additions, deletions, modifications) are made on the primary zone. The server hosting the primary zone is the primary nameserver for that zone.
Secondary Zone: A read-only copy of the zone. Secondary zones are created via zone transfers from a primary zone or another secondary. They provide redundancy and load distribution.
Stub Zone: A read-only copy that contains only the SOA record, NS records, and glue A records for a delegated zone. Stub zones are used to improve name resolution efficiency by keeping track of authoritative servers for child zones without having full zone data.
Forward Lookup Zone: Resolves hostnames to IP addresses (A or AAAA records).
Reverse Lookup Zone: Resolves IP addresses to hostnames (PTR records). The zone name is derived from the IP address range (e.g., 1.168.192.in-addr.arpa for 192.168.1.0/24).
Zone Transfer Mechanisms
Zone transfers are the process of replicating zone data from one DNS server to another. There are two types:
Full Zone Transfer (AXFR): Transfers the entire zone file. AXFR is used when a secondary server is first configured or when the zone data has been corrupted and needs a complete refresh. The secondary sends an AXFR request, and the primary responds with all resource records in the zone.
Incremental Zone Transfer (IXFR): Transfers only the changes since the last transfer. IXFR is more efficient because it reduces bandwidth and processing overhead. It requires both servers to support IXFR and the primary to maintain a history of changes. RFC 1995 defines IXFR.
Zone Transfer Process
SOA Query: The secondary server queries the primary for the SOA record of the zone. The primary responds with its current SOA serial number.
Comparison: The secondary compares the primary's serial number with its own. If the primary's serial is higher, the secondary requests a zone transfer.
Transfer Request: The secondary sends an AXFR or IXFR request. AXFR requests use TCP port 53 (not UDP) because zone data can be large and requires reliable delivery. IXFR also uses TCP.
Data Transfer: The primary sends the zone data. For AXFR, it sends all records. For IXFR, it sends only the differences.
Update: The secondary updates its zone data and sets its serial number to match the primary's.
SOA Timers and Their Role
The SOA record contains five timer values that control zone transfer behavior:
Serial Number (32-bit): Used to track zone version. When the zone is updated, the serial number should be incremented (commonly using YYYYMMDDNN format). Secondary servers compare serials to determine if an update is needed.
Refresh Interval (default: 3600 seconds / 1 hour): How often the secondary should query the primary for the SOA record to check for changes.
Retry Interval (default: 600 seconds / 10 minutes): How long the secondary should wait before retrying after a failed refresh attempt.
Expire Interval (default: 86400 seconds / 24 hours): How long the secondary can continue to serve its zone data without contacting the primary. After this period, the secondary stops answering queries for the zone (expired).
Minimum TTL (default: 3600 seconds / 1 hour): The default TTL for all records in the zone. Also used as the negative caching TTL (NXDOMAIN responses).
Zone Transfer Security
Zone transfers can expose sensitive internal network information if not secured. Best practices include:
Allow only authorized secondaries: Use ACLs (allow-transfer directive in BIND) to restrict which servers can request transfers.
Use TSIG (Transaction Signatures): TSIG uses shared secret keys to authenticate zone transfer requests and responses. This prevents unauthorized transfers and man-in-the-middle attacks.
Use DNS NOTIFY: The primary sends a NOTIFY message to secondaries when the zone changes, prompting them to check for updates. This reduces the time for convergence.
DNS NOTIFY (RFC 1996)
DNS NOTIFY is a mechanism where the primary server sends a notification to secondary servers when the zone changes. The notification contains the name of the zone that changed. Secondaries then query the primary for the SOA and decide whether to initiate a zone transfer. NOTIFY is sent to each secondary's IP address (port 53).
Active Directory Integrated Zones
In Microsoft DNS, zones can be integrated into Active Directory. This provides multi-master replication, meaning any domain controller can update the zone. Zone transfers are replaced by AD replication, which is more efficient and secure. AD-integrated zones support secure dynamic updates.
Command Examples
BIND (named.conf)
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { 192.168.1.10; };
also-notify { 192.168.1.10; };
};
zone "example.com" {
type slave;
file "/etc/bind/db.example.com";
masters { 192.168.1.5; };
};Windows DNS (PowerShell)
Add-DnsServerPrimaryZone -Name "example.com" -ZoneFile "example.com.dns"
Add-DnsServerSecondaryZone -Name "example.com" -ZoneFile "example.com.dns" -MasterServers 192.168.1.5
Set-DnsServerPrimaryZone -Name "example.com" -Notify Servers -SecondaryServers 192.168.1.10Verification Commands
dig example.com AXFR (perform a zone transfer from the server specified)
nslookup -type=soa example.com (view SOA record)
nslookup -type=ns example.com (view NS records)
dnscmd /zoneprint example.com (Windows: print zone contents)
Get-DnsServerZone -Name "example.com" (PowerShell)
Interaction with Other Technologies
DHCP: Dynamic DNS (DDNS) allows DHCP servers to update DNS records when clients receive IP addresses. This requires the DNS zone to allow dynamic updates.
Active Directory: As mentioned, AD-integrated zones use AD replication instead of traditional zone transfers.
DNSSEC: DNSSEC adds digital signatures to DNS records. Zone transfers of signed zones include the RRSIG records. Secondary servers must support DNSSEC to serve signed zones.
Cloud DNS: In cloud environments like AWS Route 53, zone transfers are not supported; instead, DNS is managed via APIs. However, you can transfer zones into or out of cloud DNS using tools like aws route53 create-hosted-zone and zone file import/export.
Secondary Queries SOA
The secondary DNS server sends a DNS query for the SOA record of the zone to the primary server. This query uses standard UDP (or TCP if truncated). The primary responds with the current SOA record, which includes the serial number, refresh, retry, expire, and minimum TTL values. The secondary extracts the serial number and compares it to its own serial number for that zone. If the primary's serial is higher, the secondary proceeds to request a zone transfer. If equal, no transfer is needed. If lower, this indicates a potential misconfiguration (e.g., serial not incremented) and the secondary may log an error.
Secondary Requests Transfer
If the primary's serial is higher, the secondary initiates a TCP connection to the primary on port 53. It sends either an AXFR query (full transfer) or an IXFR query (incremental). The choice depends on the secondary's capabilities and configuration. AXFR is always supported; IXFR requires both servers to support it. The secondary may also use IXFR if it knows the primary supports it (e.g., via the EDNS0 option). The TCP connection ensures reliable delivery of the potentially large zone data.
Primary Sends Zone Data
The primary server responds to the AXFR or IXFR request. For AXFR, it sends all resource records in the zone, including the SOA record at the beginning and end (to mark the boundary). For IXFR, it sends a sequence of differences: a SOA record with the current serial, then the records that were added or removed, then the SOA again. The primary may also include the previous SOA to indicate the version being replaced. The secondary receives the data and validates it (e.g., checks for consistency).
Secondary Updates Zone
The secondary replaces its zone data with the received records (for AXFR) or applies the incremental changes (for IXFR). It updates its serial number to match the primary's. The secondary then sets its refresh timer based on the SOA refresh interval. If the transfer fails or is incomplete, the secondary will retry after the retry interval. If the transfer succeeds, the secondary can now serve the updated zone data to clients.
Primary Sends NOTIFY
If DNS NOTIFY is configured, the primary sends a NOTIFY message to all configured secondary servers immediately after the zone is updated (even before the secondary's refresh timer expires). The NOTIFY is sent via UDP to port 53 of each secondary. It contains the zone name. Secondary servers that receive a NOTIFY will query the primary for the SOA and compare serials, potentially triggering a zone transfer before the scheduled refresh. This reduces convergence time.
Enterprise DNS Redundancy
In a typical enterprise, you have a primary DNS server (e.g., BIND on Linux) and multiple secondary servers in different data centers or geographic regions. The primary hosts the read-write zone; secondaries provide read-only copies. This setup ensures that if the primary fails, clients can still resolve names using secondaries. Zone transfers are configured with allow-transfer ACLs to restrict which IPs can pull the zone. In production, you might set the refresh interval to 15 minutes (900 seconds) to balance timeliness with load. A common mistake is forgetting to increment the serial number after changes; this causes secondaries to never see the update. Automated scripts often use the current date and time as the serial to avoid this.
Active Directory Integrated Zones
In a Microsoft-centric environment, DNS zones are often integrated into Active Directory. This eliminates the need for traditional zone transfers because AD replication handles the synchronization. Each domain controller can update the zone (multi-master). However, if you have a DMZ with a standalone DNS server that needs to resolve internal names, you might set up a secondary zone from an internal AD DNS server. In this case, zone transfers must be allowed through firewalls, and TSIG is used for security. The DMZ server will have a secondary zone with refresh intervals set appropriately for the slower WAN link.
Cloud Migration and Hybrid DNS
When migrating to the cloud, you might have a primary zone on-premises and a secondary zone in a cloud VPC (e.g., AWS). However, cloud DNS services like Route 53 do not support zone transfers natively. Instead, you can use a hybrid approach: run a DNS forwarder in the cloud that forwards queries to on-premises DNS, or use a DNS proxy. Alternatively, you can replicate zone data using scripts that export the zone file and import it into the cloud DNS API. This is less efficient but necessary. In such scenarios, zone transfer security is critical because the transfer traverses the internet; TSIG or VPN tunnels are used.
Common Pitfalls
Firewall blocking TCP port 53: Zone transfers require TCP; if only UDP is allowed, transfers fail. Symptoms: secondary never updates, logs show connection timeouts.
Serial number not incremented: Changes made on primary but serial unchanged; secondaries never see updates. Always increment serial.
Expire interval too short: If the primary is down for maintenance longer than the expire interval, secondaries stop serving the zone, causing resolution failures. Set expire to at least 24 hours.
Misconfigured allow-transfer: If the secondary IP is not in the allow-transfer list, the primary rejects the transfer. Check ACLs.
N10-009 Objective 2.5: DNS Zones and Zone Transfers
The exam tests your understanding of zone types, the zone transfer process, and SOA timers. Specifically:
Zone Types: Know the difference between primary, secondary, and stub zones. Stub zones are often confused with secondary zones; remember stub zones contain only SOA, NS, and glue records, not all records.
Zone Transfer Mechanisms: Understand when AXFR vs IXFR is used. AXFR is for initial or full sync; IXFR is for incremental updates. Both use TCP port 53.
SOA Timers: Know the default values: refresh 3600s, retry 600s, expire 86400s, minimum TTL 3600s. Be able to interpret a scenario: e.g., if the secondary cannot contact the primary for 2 hours, it will continue serving because expire is 24 hours.
DNS NOTIFY: Know that NOTIFY is sent from primary to secondary to trigger immediate check. It does not transfer the zone itself; it only notifies.
Security: Understand that zone transfers should be restricted to authorized secondaries using ACLs or TSIG. The exam may ask why zone transfers are a security risk (they expose all records).
Common Wrong Answers
"Zone transfers use UDP port 53": Wrong—they use TCP because of data size and reliability. UDP is used for standard queries.
"A stub zone contains all records from the child zone": Wrong—stub zones contain only SOA, NS, and glue records. This is a common trap.
"The refresh interval determines how long a secondary serves data after losing contact": Wrong—that's the expire interval. Refresh is the check interval.
"IXFR is always used when available": Not exactly—the secondary must support it and the primary must have change history. The exam may test that IXFR is not always possible.
Key Numbers and Terms
Default SOA timers: Refresh 3600, Retry 600, Expire 86400, Min TTL 3600.
Zone transfer TCP port 53.
NOTIFY uses UDP port 53.
Serial number format often YYYYMMDDNN.
RFC 1034 (zones), RFC 1035 (zone transfers), RFC 1995 (IXFR), RFC 1996 (NOTIFY).
Edge Cases
If serial number rolls over (exceeds 2^32-1), it wraps to 0. This can cause issues; some servers treat a lower serial as older, so the secondary may refuse to update. Avoid rollover.
If the primary's serial is accidentally decreased, secondaries will not update because they expect a higher serial. This is a common exam scenario where the administrator forgets to increment.
Eliminating Wrong Answers
Focus on the mechanism: zone transfers are for replicating zone data between servers. Any answer suggesting that zone transfers are used for client resolution is wrong. Also, remember that secondary zones are read-only; any answer implying changes on a secondary is incorrect.
A DNS zone is a contiguous portion of the DNS namespace managed by a single entity.
Primary zones are read-write; secondary zones are read-only replicas.
Zone transfers use TCP port 53, not UDP.
AXFR transfers the entire zone; IXFR transfers only changes.
SOA record timers: Refresh (default 3600s), Retry (600s), Expire (86400s), Minimum TTL (3600s).
DNS NOTIFY alerts secondaries of changes but does not transfer data.
Stub zones contain only SOA, NS, and glue records.
Zone transfers should be secured with ACLs and TSIG.
Always increment the serial number when updating a zone.
Active Directory integrated zones use AD replication instead of traditional zone transfers.
These come up on the exam all the time. Here's how to tell them apart.
Primary Zone
Read-write copy of the zone
Hosted on the primary DNS server
All changes are made here
Can be a master for zone transfers
May be integrated with AD for multi-master
Secondary Zone
Read-only copy of the zone
Hosted on secondary DNS servers
Cannot be modified directly
Receives updates via zone transfers from primary
Provides redundancy and load distribution
AXFR (Full Zone Transfer)
Transfers the entire zone file
Used for initial sync or after corruption
Requires more bandwidth and time
Always supported by all DNS servers
Simple to implement
IXFR (Incremental Zone Transfer)
Transfers only changes since last transfer
Used for routine updates
Efficient for small changes
Requires both servers to support IXFR
Requires primary to maintain change history
Mistake
Zone transfers use UDP port 53 because DNS queries do.
Correct
Zone transfers use TCP port 53 because they can transfer large amounts of data that require reliable delivery and segmentation. UDP is limited to 512 bytes (or up to 4096 with EDNS0) and is connectionless, making it unsuitable for large transfers.
Mistake
A secondary zone is a writable copy of the zone.
Correct
A secondary zone is read-only. All changes must be made on the primary zone. The secondary receives updates only via zone transfers from the primary or another secondary.
Mistake
DNS NOTIFY transfers the zone data to secondaries.
Correct
DNS NOTIFY is just a notification that the zone has changed. It does not contain zone data. The secondary must still query the primary for the SOA and then initiate a zone transfer if needed.
Mistake
IXFR transfers only new records, not deletions.
Correct
IXFR transfers both additions and deletions. The primary sends a delta that includes records to be added and records to be removed. The secondary applies both types of changes.
Mistake
Stub zones are the same as secondary zones.
Correct
Stub zones contain only SOA, NS, and glue A records for a delegated zone. They are used to keep track of authoritative servers for child zones without having all the records. Secondary zones contain the full zone data.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A primary zone is the read-write copy of a DNS zone where all changes are made. A secondary zone is a read-only copy that receives updates via zone transfers from the primary. Secondary zones provide redundancy and offload query traffic. On the N10-009 exam, remember that secondary zones cannot be modified directly.
Zone transfers use TCP port 53 because they can involve large amounts of data that require reliable delivery and segmentation. UDP has a 512-byte limit (or 4096 with EDNS0) and is connectionless, making it unsuitable for transferring entire zone files. Standard DNS queries use UDP for efficiency.
The serial number in the SOA record is used by secondary servers to determine if the zone has changed. When the primary's serial is higher than the secondary's, the secondary initiates a zone transfer. The serial should be incremented every time the zone is updated. A common format is YYYYMMDDNN.
DNS NOTIFY is a mechanism where the primary server sends a notification to secondary servers when the zone changes. The notification (UDP port 53) includes the zone name. Secondaries then query the primary for the SOA and compare serials. If the serial is higher, they initiate a zone transfer. NOTIFY reduces convergence time by triggering immediate checks.
A stub zone is a read-only copy of a zone that contains only the SOA record, NS records, and glue A records for a delegated zone. It is used to improve name resolution efficiency by keeping track of authoritative servers for child zones without replicating all records. For example, you might use a stub zone to resolve a subdomain without transferring its entire zone.
Zone transfers should be restricted to authorized secondary servers using ACLs (allow-transfer directive). Additionally, TSIG (Transaction Signatures) can be used to authenticate the transfer and prevent tampering. Without these, anyone could request a zone transfer and obtain all DNS records, which is a security risk.
The secondary will continue to serve its zone data until the expire interval (default 24 hours) is reached. After that, the secondary stops answering queries for the zone. The refresh and retry intervals determine how often it tries to contact the primary. If the primary comes back before expiry, the secondary will sync normally.
You've just covered DNS Zones and Zone Transfers — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?