What problem are you having?
I am having a problem related to zone transfers.
Cause: The DNS Server service is stopped, or the zone is paused.
Solution: Verify that the master (source) and secondary (destination) Domain Name System (DNS) servers that are involved in completing the transfer of the zone are both started and that the zone is not paused at either server.
Cause: The DNS servers that were used during a transfer do not have network connectivity with each other.
Solution: Eliminate the possibility of a basic network connectivity problem between the two servers.
Using the ping command, contact each DNS server by its IP address from its remote counterpart.
For example, at the source server, use the ping command to test IP connectivity with the destination server. At the destination server, repeat the ping test, substituting the IP address for the source server.
Both ping tests should succeed. If they do not succeed, investigate and resolve intermediate network connectivity issues.
Cause: The serial number is the same at both the source and destination servers. Because the value is the same at both servers, no zone transfer occurs between the servers.
Solution: Using DNS Manager, perform the following tasks:
Increase the value of the serial number for the zone at the master server (source) to a number greater than the value at the applicable secondary server (destination).
After you increase the serial number at the master server to a higher value than is used currently at the secondary server, initiate zone transfer at the secondary server.
When you are working in DNS Manager, you can view the zone serial number on the Start of Authority (SOA) tab in the applicable zone properties. To increase this number in the zone, click Increment.
Cause: The master server (source) and its targeted secondary server (destination) are having interoperability-related problems.
Solution: Investigate possible causes for any problems that might be related to interoperability between DNS servers running Windows Server 2008 and other DNS server implementations, such as an older version of the Berkeley Internet Name Domain (BIND) distribution.
Older BIND servers use an uncompressed zone transfer format. By default, servers running Windows Server 2008 (and later version BIND servers) use a faster, compressed format during zone transfers. To accommodate zone transfer with older BIND servers, you must change advanced server options at your DNS servers running Windows Server 2008.
Another possible interoperability issue is the use and inclusion of Windows Internet Name Service (WINS) forward lookup (WINS) resource records in a zone or their counterpart, the WINS reverse lookup (WINS-R) resource record that is used for reverse lookup zones. BIND servers do not recognize these records when the records are included in zone data that is being transferred, and they can flag these records as bad data, possibly failing the zone transfer.
To prevent these records from being used or included in zone transfers to BIND-based servers and other servers that do not recognize them, select the Do not replicate this record option when you configure WINS properties at the applicable zone.
For more information, see Enable DNS to Use WINS Resolution.
Cause: The zone has resource records or other data that cannot be interpreted by the DNS server.
Solution: Verify that the zone does not contain incompatible data, such as unsupported resource records types or data errors.
In most cases, the DNS Server service supports all resource record types that are approved and required for Internet-standard DNS usage.
Also, verify that the server has not been configured in advance to prevent loading a zone when bad data is found and investigate its method for checking names. You can configure these settings with DNS Manager.
Cause: Authoritative zone data is incorrect.
Solution: If a zone transfer continues to fail, ensure that the zone does not contain nonstandard data.
If you edit zone files manually, be aware that records must be formatted and used according to standard record usage and formatting guidelines as specified in the Request for Comments (RFCs) for DNS. In most cases, user input and data errors can be avoided if records are added and managed with DNS Manager.
To determine if incorrect zone data is a likely source for a failed zone transfer, look in the DNS server event log for messages. You can also use the nslookup command with the -ls option to simulate and test a zone transfer, while observing if the data that is returned terminates before full transfer of the zone is complete.
I am trying to use a zone delegation, but it appears to be broken.
Cause: Zone delegations are not configured correctly.
Solution: Review how zone delegations are used, and revise your zone configurations as needed.
Zones contain information about DNS domains and subdomains. For each new zone you create, the zone originally begins as a single-node database for one DNS domain. As necessary, new subdomain nodes can be added directly below the original (parent) domain and stored as a single zone. Sometimes, when new subdomains remain part of the same zone, they are called subzones.
If they are used as subzones, new subdomains are retained as part of the zone and replicated and updated along with the zone as a single entity. You can, however, delegate subdomains away and manage them in their own zones. For each subdomain that is delegated to its own zone, the parent zone must have delegation records added to it.
You can use the New Delegation Wizard in DNS Manager to simplify the addition of these records.
I am having a different zone problem than the ones described here.
Cause: My problem is not described above.
Solution: Search TechNet (
If you are connected to the Internet, the latest operating system updates are available at Microsoft Update (