A DNS Zone is a contiguous portion of a DNS namespace managed by one or more servers. Zones contain resource records that specify the name of the DNS Server authoritative for the zone (called a Start of Authority (SOA) record), and names and IP addresses of all name servers in the zone (called Name Server (NS) records), and names and addresses of other hosts (called A records) and their aliases (called CNAME records).
Even in SME organizations, it is reasonable to assume you need not only install and configure one DNS server for your network, but also have a second to reduce the workload on the first DNS server, provide a fallback should one DNS server fail, and if positioned and configured correctly, help reduce excessive network traffic.
When more than one DNS Server is deployed, data consistency between the DNS servers and their zone information is important. To provide synchronization and current information for all DNS servers you need to ensure DNS zone transfers\replication occurs.
There are at least 3 possible DNS Server zone types:
Primary
Secondary
Stub
In addition you have the option to make the Primary or Stub zones Active Directory integrated.
There is actually a fourth DNS Server type called a Caching Only DNS server. Such a DNS server has no zones, it simply caches the results of DNS queries it has received and passed on. Typically DNS servers allow cached information for a default Time to Live (TTL) of 1 hour.
A primary zone is the main zone, providing editable\writable DNS data, allowing the DNS Server to answer DNS name resolution queries from clients and other servers authoritatively for the portion of the DNS namespace it is setup for. By default this zone stores its data in a file called "zone_name.dns" in %systemsroot%\system32\Dns. Here "zone_name" = name assigned to zone when created.
A secondary zone is a read only copy of the DNS data file, but still provides the ability to answer DNS name resolution queries from clients and other servers authoritatively for the portion of the DNS namespace it is setup for. These zones help ease the excessive traffic a primary zone may otherwise receive, and can answer queries if the primary server fails. The primary zone acts as a master zone for a secondary zone, and a secondary zone can act as a master zone for another secondary zone. Secondary zones update their data by querying master zones at pre-set time intervals and if data has changed a zone transfer to the secondary updates its data.
A stub zone is similar to a secondary zone, but only keeps limited DNS data specifying which DNS server is a master server and thus authoritative for the domain in question. These zones are useful when wishing to reduce zone transfer\replication traffic as they simply pass on requests to authoritative servers, otherwise it uses its local DNS cache information to resolve DNS queries for clients.
Used to maintain/improve DNS name resolution efficiency
Read-only copy of a zone containing specific resource records
Records in zone identify authoritative DNS servers for domain
Typically used in a parent zone to enable the parent to keep up to date with Name Servers in the child domain
Stub zones contain only:
Start of Authority (SOA) record
Name Server (NS) records
(A) records
An administrator of stub zone cannot modify resource records, and changes must be made in original primary zone.
Both Primary and Stub Zones can be integrated into an Active Directory based LAN. When AD integrated, the DNS data is no longer kept in a simple text type file (zone_name.dns), but instead is stored in the Active Directory database where it mingles with the rest of the network data that this object database stores. Integration of DNS with AD is favorable for security and performance reasons, and prevents rogue entries from unauthorized clients registering records with DNS.
When DNS zones are not integrated with Active Directory the replication is actually called a Zone Transfer, where master DNS servers are queried by secondary servers and zone data is transferred for update from the master to the secondary.
DNS Replication is the process of transferring DNS data when it changes on one AD integrated DNS server to another AD integrated DNS server, keeping all DNS data in all DNS servers on the network synchronized.
DNS zone transfer (relevant when DNS servers are non AD integrated servers) can occur as a result of any of 3 events:
Refresh interval is reached for SOA record
Notification has been set to update other DNS servers when DNS data changes
DNS server is rebooted
Shown below is the Refresh Interval which when reached triggers incremental DNS data zone transfer.
For non AD integrated zones the Master Primary DNS server can notify secondary DNS server when changes occur.
The "Zone Transfers" tab has a checkbox to allow zone transfers to other DNS servers with 3 options. You can specify any server, only to those listed in the Name Servers tab, or to specific servers by entering their IP addresses. The 2 images below show the second option using the "Name Servers" tab.
After selecting the 2nd radio button above, you can click the "Name Servers" tab and view/configure the DNS servers that will receive zone transfers.
You can force a secondary DNS Server to reload DNS data from the Master Server (Primary) by right clicking on the server and selecting "Reload from Master" as shown below.
This can also be accomplished from the command line using dnscmd.exe with switches:
/ZoneReload = Reload /ZoneUpdateFromDS = Reload /ZoneRefresh = Transfer from Master
With AD integrated DNS, DNS replication is taken care of as part of the normal AD replication process between domain controllers within a domain environment. When DNS is AD integrated the zone settings on the DNS server are ignored for DNS transfer activity as the DNS data is moved between DNS servers as part of general AD replication traffic.
DNS data can be stored in several ways in the AD database (NTDS.DIT), due to the fact that the AD database is separated into distinct partitions or naming contexts (domain partition, configuration partition, schema partition, global catalog and application partition).
The DNS data can be stored in the application partition (normal location), the domain partition or in a custom built AD partition.
It its always best to ensure that DC servers hosting integrated DNS servers should point not just to themselves for a preferred DNS Server, but to an alternate DNS Server as well. In other words, have at least 2 DNS servers when using AD integrated DNS. This will prevent Event ID 4013, which in effect causes an infinite loop with Active Directory waiting for DNS, and DNS needing Active Directory before it can start.
