Not a geek Leftnot a geek Right

Houston Computer Specialists Since 1984

About Customer Home Novell Microsoft Support Internet Virus Links Contact

Houston, Texas 77055

DNS Troubleshooting

Enable/disable Recurrsion

  1. Properties

  2. Advanced

  3. Disable resursion


Failed to find nameservers of

No nameservers found at child.


Solution:  restart the nameserver computer

restart the switch between nameserver and router

*** update host name ip at Godaddy ***

adjust nameservers at ns1


Spiceworks: How DNS Works

Delegation Not Found at Parent

If your modem and router are separate devices, perhaps they are not synchronized properly.  Unplug both for about 60 seconds, plug in the modem until it becomes ready, plug in the router.  This solved my delegation problem.

Site won't load without "WWW"

  1. Zone must have a forward entry without the "www" -> host A (same as parent folder)
  2. Zone must have a reverse entry without the "www
  3. Apache server must have virtual server without the "www"


NSLOOKUP shows wrong or no server name.

Set a reverse pointer to the interface that is your local DNS server.

Ten Things to Check

Check the TCP/IP settings, run a few utilities to verify the zone records.
Identify the most common domain name system issues that cause problems for AD and Exchange and how to avoid them in the first place or isolate and resolve them if they occur in production.

1. TCP/IP Configuration Points to Public DNS Servers
This is by far the most common DNS error. Each network interface has a set of TCP/IP settings that lists the DNS servers used by that interface.

If the TCP/IP settings for a member computer specify the IP address of a public DNS serveróperhaps at an ISP or DNS vendor or the companyís public-facing name serveróthe TCP/IP resolver wonít find Service Locator (SRV) records that advertise domain controller services, LDAP, Kerberos and Global Catalog. Without these records, a member computer canít authenticate and get the information it needs to operate in the domain.

This can happen when you upgrade from NT 4.0 to Windows 2000 Server or Windows Server 2003. The desktops use DHCP with a scope option that includes the IP addresses of two DNS servers managed by the customerís broadband provider. The servers use static mappings to the same external DNS servers.

During the PDC upgrade, you install DNS because DCPromo tells you to. You let DCPromo configure a zone file that matches the DNS name you selected for AD. You forget to reconfigure the TCP/IP settings of the newly upgraded DC to point at itself for DNS. You also forget to reconfigure the DHCP scope options so the clients still point at the ISPís DNS server instead of the new DC.

The result? The DC doesnít register SRV records in the new DNS zone and the clients wouldnít be able to find them, even if it did. The member computers donít know that the domain has been upgraded to AD unless they just happen to authenticate at the PDC. The other computers get no group policies, so you can forget about any carefully-orchestrated centralized management scheme.

Fixing this problem couldnít be simpler. Once you enter the correct DNS entries in TCP/IP settings at the DC, populate the zone with SRV records by stopping and starting the Netlogon service. (If youíve installed the Support Tools, you can run Netdiag /fix.) Now change the DHCP scope option to point clients at the new DC for DNS, then chase down any statically mapped servers and desktops and correct their DNS entries. Read the rest of the column for suggestions about resolving Internet names.

2. Improper DNS Suffix Handling

DNS servers insist that every query specify a target domain.  The DNS resolver in Windows strikes a compromise. It accepts the flat name from the user then appends a suffix to form a FQDN it can send to a DNS server. The resolver obtains this DNS suffix from one of several places.

AD domain name. The domain to which the desktop or server belongs has a DNS name as well as a flat name. You can see this suffix in the Properties of the local system (Figure 1). The TCP/IP Settings window calls this the Primary Suffix. If a query using the primary suffix fails, and the Append Parent Suffixes option is checked, the resolver strips the leftmost element from the primary suffix and tries again. For example, the resolver first appends then

Interface suffix. The TCP/IP settings for each network interface can have a unique DNS suffix, populated either statically or with DHCP. The user interface calls this the Connection-specific Suffix. Itís best to leave this field empty in deference to the Primary Suffix. If you do give it a value, the resolver first tries the Primary Suffix, then the Connection-specific Suffix, then the parent suffixes of the Primary Suffix.

Search table. The TCP/IP settings for all network interfaces share an optional set of DNS suffixes that the Registry calls a SearchList. If you elect to use the entries in a search list, the resolver ignores the primary suffix, its parents, and the connection-specific suffix.

In the default suffix search configuration, a client in the edu domain wonít find a host in the domain. If you want a flat name to resolve to the hostís actual FQDN regardless of the hostís domain, select the Append These DNS Suffixes option and list each domain in the order you want them tested. Donít forget to include the FQDN of the local domain as the first option on the list.

3. Improperly Configured Forwarding
Ordinarily, when a client confronts its DNS server with a request for a resource record in an outside domain, the DNS server searches for a name server in the target domain and submits the query to that server. This standard query resolution has a couple of problems. First, the internal server can get so preoccupied chasing down recursive queries for public hosts that it runs out of resources to handle queries for its own zones. Worse still, the internal server must reach through the firewall and connect to a variety of DNS servers, some of which could have traps that play malicious games with DNS requests.

An internal root server doesnít need to waste energy or cause security problems by chasing referrals.  This process is called forwarding. The server that gets the job of doing the recursive queries and delivering the results is called a forwarder.

If you have a business relationship with an ISP, you might get an agreement with them to use their DNS servers as forwarders. This agreement would allow your DNS server to send recursive queries to the ISPís name servers. Otherwise, you can put a caching-only server in your perimeter network to use as a forwarder. If you have a public-facing DNS server in your DMZ that acts as the authoritative server for your public DNS domain, donít use it for a forwarder. Check out Error #7 to see why.

If you have a multi-tiered private DNS namespace supporting AD, configure the DNS servers in the child domains to use the internal root DNS servers as forwarders. This allows servers in the child domains to locate SRV and CNAME resource records in the root domain. Without these records, they canít replicate. Also, the root zone holds Global Catalog records for the entire forest. Exchange uses these records to find Global Catalog servers to use for message routing and group membership expansion. Outlook can be configured to find a local Global Catalog server from which to obtain the Global Address List.

Donít forget to enable forwarding at each child DNS server. Do this even if you integrate the zone into AD. DNS servers store forwarding parameters in the local Registry, not in AD.

4. Improper Zone Transfer Configuration
In a standard text-based DNS zone, only the primary master DNS server has full Read/Write access to the zone file. Secondary DNS servers hold read-only replicas of the zone file. A resource record called Start of Authority (SOA) identifies the primary master server. Figure 2 shows the SOA properties.


Figure 2.

The DNS zone properties showing the Start of Authority tab.
Each change to the zone increments a serial number in the SOA record. Two zones in sync have matching SOA serial numbers. The primary master DNS server retains each zone change in a separate log file to use for iterative transfers. In iterative transfers, a secondary DNS server only pulls changes since the last zone transfer. The secondary servers keep track of zone changes using the SOA serial number.

Itís not uncommon for DNS administrators with BIND experience to make changes directly to a zone file. This can cause zone transfer issues with Windows DNS because not all updates reside in the main zone file. Itís usually a good idea to stick with the graphical interface or use a command-line tool such as Dnscmd to make changes to a zone.

Windows DNS servers use TCP rather than UDP for a zone transfers, so if you have an intervening firewall, be sure it allows TCP connections over port 53. Also, Windows DNS servers donít use Port 53 as the source port for zone transfers. So when configuring a firewall, expect packets in the zone transfer to come from any port above 1023.

Donít allow unrestricted zone transfers. Configure the zone to allow transfers only to servers whose name appears in the Name Server list, as shown in Figure 3. The Name Server list doesnít get populated automatically. Manually add the FQDN and IP address of each secondary server. By placing a secondary server on the Name Server list, you also enable the primary master to send notifications of changes to the secondary server. Itís worth the trouble. Disable zone transfers completely at secondary servers unless you want another secondary to pull the zone from it.

Figure 3. DNS Zone properties, showing the Name Server list with authorized secondary DNS servers.

Before you make the switch to using AD-integrated zones, remove secondary zones from any DCs. If you forget to do this, you put the DC in the awkward position of getting a replica via standard zone transfers and a copy in AD. Remove the secondary zone then stop and restart DNS to see the AD-integrated zone.

Test zone transfers using a tool called dig that comes with the BIND implementation from the Internet Systems Consortium (ISC). The most current version of BIND (and dig) is 9.2.3. Get the Win32 binaries from

Using dig, you can initiate full or incremental zone transfers and see the results. For example, to test an incremental transfer, first query for the SOA record at the primary master to see the current serial number. Then request an iterative transfer (IXFR) specifying an earlier SOA serial number. For example, if the SOA serial number is 88, the dig syntax to do an iterative transfer of the last zone change would be similar to the code shown in Listing 1.

Listing 1. The dig syntax to transfer the last name change iteratively.

dig ifxr=87
; <>> DiG 9.2.3 <>> @ ixfr=89
;; global options: printcmd 3600 IN CNAME 3600 IN SOA 90 900 600 86400 3600

This listing shows the SOA and a CNAME record called that points at a server named

5. Failure to Verify Dynamic Update of Resource Records
Every modern Windows client periodically registers its A and PTR record with the Start of Authority (SOA) server for the forward and reverse lookup zones, respectively. The clients send their record updates to the SOA servers because, in standard BIND-style DNS, only the SOA has a Read/Write copy of the zone file. In AD-integrated zones, any DC running DNS can update a zone record.

The DHCPClient service on a Windows computer handles the dynamic updates for each network interface. Donít disable this service on a statically mapped server; youíll prevent the server from updating its DNS records if you (or a colleague, after youíre long gone) change the server name or its IP address.

DCs use the Netlogon service to register their SRV records along with the CNAME records that contain each DCís Globally Unique Identifier (GUID.) These CNAME records are vital for replication. To assure accurate entries, the Netlogon service updates DNS hourly using the content of a file called Netlogon.dns, located in %windir%\system32\config.

The SRV and CNAME records have a format that determines the recordís location in the DNS hierarchy within the zone. This hierarchy is important because domain members query for SRV records at specific locations. If these lookups fail, the machine gives up and uses local logon credentials.

Invalid or missing SRV records can also cause problems for Exchange 2000 and Exchange Server 2003. Modern Exchange relies on DCs to store information about the Exchange organization, and uses the Global Catalog extensively to support messaging routing and to help down-level Outlook clients expand the membership distribution lists. By the same token, newer Outlook clients can be configured to use local Global Catalog servers to obtain address lists, so they rely on DNS as well.

A fast way to check for proper SRV record registration is to use the Netdiag utility that comes in Support Tools. Netdiag performs a suite of checks, but hereís the syntax to perform just the DNS test with verbose output saved to a Netdiag.log file:

netdiag /v /l /test:dns

This test walks through every entry in the Netlogon.dns file and verifies that the server has all the proper DNS entries. If you have multiple DCs, youíll get a minor error because the DNS query results in all DCs, but the overall result will come up as a PASS if all the results match.

If you get a FAIL on the Netdiag test, use the log file to determine the problem record. You can use Netdiag /fix to apply the contents of the Net-logon.dns file to DNS again. If this resolves the problem and it doesnít reoccur, then allís well. If the problem happens again, youíll have to do more digging.

One particularly aggravating source of SRV record problems isnít a lack of records but too many records. If you have a DC with multiple interfaces, the default action of DHCPClient is to register each of the interfaces. If one of the interfaces connects to a private network, such as a dedicated backup network, then clients will fail when they get that IP address, forcing them to go back to DNS to get another SRV record and slowing down the logon process. This can also happen if you have a management card in the server that presents its network or modem interface as a standard network connection which DHCPClient insists on registering.

6. Failure to Properly Delegate Child Zones
All DCs in a forest share a common copy of the Configuration and Schema naming contexts, so DCs need to find replication partners regardless of their domain. AD identifies domains and DCs in DNS using CNAME records that correlate a serverís GUID and its FQDN. Figure 4 shows the list of CNAME records for the forest.

DNS Management Console
Figure 4. The DNS management console showing CNAME records for DCs in an AD forest.
If a CNAME record references a server in a child domain, the root DNS server needs to go to a DNS server in the child domain to retrieve a copy of the serverís A record. It gets the name of this DNS server by way of delegation.

In delegation, the parent zone contains NS records that specify the names of DNS servers in the child domains along with A (glue) records that contain their IP addresses. Win2K and Windows 2003 use a New Delegation Wizard to create these records. The wizard walks you through selecting the child domain name and identifying name servers in the child domain.

If someone takes down a child DNS server for maintenance, or decommissions it entirely, without notifying the DNS administrator in the parent domain, the delegation records in the parent zone become invalid. This is called lame delegation. You can also get lame delegations by blocking zone transfers to a secondary server if the secondary server has an NS record in the parent zone. This sometimes happens during an overzealous security sweep.

In an AD forest, lame delegations can cause replication failures as the root DNS servers grope for the IP addresses of the DCs in the child domains. Youíll get Event Log entries complaining about RPC (Remote Procedure Call) connection errors and the inability of the Knowledge Consistency Checker to get a complete spanning tree topology. Lame delegations can also cause connection failures when desktops in one domain try to connect to servers in other domains, although this might not be obvious right away if you use WINS.

If you deploy Windows 2003 DNS servers, you can avoid lame delegations by using stub zones. This feature creates a small zone file on the parent DNS server populated with copies of the SOA, NS, and A records from the child zone. The parent DNS server periodically refreshes the stub zone contents, drastically reducing the chance of having a lame delegation.

My favorite tool for diagnosing delegation problems is the DNSLint utility from Microsoft. You can download DNSLint from

DNSLint is a command-line utility that does two sets of tests: one to determine if your DNS configuration supports a specified AD domain, and one to determine if your DNS configuration meets standard practices for a zone. For example, DNSLint determines the name servers for a zone then checks that each server responds to a request at UDP Port 53 and that each server has matching, valid SOA records and NS records. It also checks for valid MX (Mail eXchange) records that point to e-mail servers in the target DNS domain.

7. Failure to Secure Public- Facing DNS Servers
For security, you want all internal servers to rely solely on forwarders to resolve Internet names. Donít let your internal servers roam the Internet looking for name servers. Select the ďDo not use recursion for this domainĒ option when configuring forwarding. Figure 5 shows an example. This essentially makes your internal DNS server a slave of its forwarders; so specify two or more forwarders and try to use servers in different subnets, if possible. You donít want a network failure at your ISP to keep your clients from resolving DNS names.

Now letís turn attention to the servers youíll use as forwarders. Itís important to keep the two primary DNS functionsócaching and zone table lookupsóon separate servers. If you allow your primary public DNS server to accept recursive queries and cache the results, you open yourself up for cache pollution. Thatís why you want to install a caching-only server in your DMZ to act as a forwarder, rather than using your public DNS server as a forwarder.

For example, letís say your DNS server gets a recursive query for It finds the name server for and asks for the www host record. In return, it gets the host record but it also gets a flock of name server (NS) records for domains such as, and so on, along with glue records that have IP addresses pointing at nefarious Web sites. Check the option to Disable Recursion for all public-facing authoritative DNS servers.

You should also enable cache pollution filtering in the DNS server Advanced properties. Do this for any server that accepts recursive queries, internally or externally. Cache pollution filtering tells DNS not to cache NS and glue records for domains outside the authoritative zone of the name server that sent them and not to cache glue records for the responding serverís authoritative zone, just in case a bogus name server impersonates the actual server.

Block all traffic to public-facing DNS servers except for UDP port 53. On the private side of the DMZ, youíll need to open TCP Port 53 and all ports above 1023 to permit zone transfers between multiple DNS servers in the perimeter network. You can protect this traffic using IPSec if your firewall accepts IPSec traffic.

For public-facing servers, take a look at the advice in RFC 2870, Root Name Server Operational Requirements. Some of the restrictions apply only to the gTLD server operators, but the suggestions and requirements for maintaining a secure, safe DNS platform are worth your consideration. Also, take a trip to www.dnsreport. com to get a great quick-and-dirty analysis of whether your public-facing DNS servers exhibit common DNS problems.

8. Failure To Properly Secure Resource Records
If you use a BIND-style primary master to store a zone, you shouldnít allow dynamic updates. Windows canít secure updates to a text-based zone file. Any machine can assert itself as an existing host and overwrite the A record with a new IP address. This essentially allows a machine to hijack the DNS records of another machine.

If you want to use dynamic updates for a zone, integrate the zone into AD and permit secure updates only. This requires a client to use Kerberos to validate its identity, then initiate a secure transaction to obtain a signing key that it can use to digitally sign the update request. RFC 2930, ďSecret Key Establishment for DNS,Ē documents this method, which can only be used by modern Windows clients (Win2K, Windows XP and Windows 2003).

Other DNS servers support secure dynamic updates, but not using this method. Examples include the current version of BIND, Lucent VitalQIP and Incognitoís DNS Commander. These servers use a form of DNS security that requires a shared secret key. Windows clients donít support shared secret keys. For more information about DNS Security (DNSSEC), read the RFCs listed at

9. Incorrect, Outdated or Unreachable DNS Servers
Anyone can get in a hurry and type an incorrect IP address in a host record or misspell a server name in a CNAME record. DNS doesnít validate your entriesóit assumes youíre a consummate IT professional and accepts your input unquestioningly. For this reason, itís a good idea to test every new entry you make into a zone. If you do this as a habit, the test becomes a reflex.

The best test of a new A or CNAME record is usually a quick ping right at the console of the DNS server or your workstation. Take a couple of precautions to keep from getting fooled by caching. Both the DNS server and the local DNS resolver cache any records they receive for a period of time determined by a TTL setting in the record. The SOA for the zone determines the default TTL, which is one hour for Windows DNS servers. Clear the local cache using ipconfig /flushdns. For the server, use the Clear Cache option in the serverís property menu in the DNS console or use the Dnscmd utility with the syntax dnscmd /clearcache.

Typos arenít the only source of misinformation in DNS. You can get interesting problems if you remove a member server from service but forget to remove the corresponding A and PTR entries from DNS. Or you might remember to remove the A record but forget to look for any CNAME records that reference the A record. This can be difficult to troubleshoot if you reference multiple servers with the same host name. Windows DNS uses round robin load sharing; so if you take a server down for maintenance and forget to remove the A record from DNS, not every client gets an invalid A record. Windows DNS also uses round robin for cached entries, so flush the cache if you take a DNS server down for maintenance.

You also get invalid DNS entries if you use AD-integrated zones and demote a DC that was also a DNS server. The server still has DNS running, but has no local zones so it starts acting as a caching-only server. Depending on the forwarding configuration and NS records stored in the local Registry, it might even appear to work normally, which is unfortunate. It would be better if it failed completely so you could fix it right away.

Clients can also get invalid information if you set up a public-facing DNS server behind a NAT firewall and the server has glue records that reference private IP addresses. A typical NAT firewall doesnít translate the IP address in glue records, so the DNS server passes out referrals to servers that canít be touched from outside the firewall. You should avoid publishing private addresses entirely or get an application layer gateway capable of translating glue records.

10. Lack of Fault Tolerance
As systems administrators, weíre trained to think about the possibility of server failures and operational flexibilities. You would probably not set up a single DNS server in a large enterprise because your entire computing operation would grind to a halt if you take the server down for maintenance. But would you put the second DNS server on the same rack as the first? Or in the same subnet? Or even in the same server room?

Fault tolerance is all about assessing business risks, and if your business relies heavily on DNS, it makes sense to put some thought into maintaining continuity of service. Youíll get a big head start by integrating your DNS zones into AD. This allows you to use any DC in the domain as a primary master DNS server, eliminating the single point of failure in standard BIND-style DNS. Also, because each DC represents itself as the SOA server for the zone, its DNS clients do their dynamic updates locally rather than sending them across the WAN to a single primary master.

If you do decide to use a standard text-based zone, decide in advance which secondary server youíll promote in the event of a failure of the primary master or a loss of the network connections to the primary master. Scheduling maintenance can be tricky, because you donít know when a client will attempt a dynamic update, but as long as you have secondary servers, the clients wonít lose the ability to do read-only queries. However, a zone with a Windows SOA expires after 24 hours, so donít dilly-dally with getting the primary master back on line.

If your organization covers a large chunk of planetary geography, you may want to consider putting the _msdcs portion of the root domain into its own zone and putting a secondary of that zone on all your DNS servers. This allows DCs to find the CNAME records of their replication partners without querying across the WAN.

If you use AD-integrated zones, a common question arises about where to point the DCs themselves for DNS lookups. For the most part, you can point a DC at itself and specify an alternate DNS server in the same site.

Thereís an exception to this rule. In the forest root domain, donít point the DCs at themselves. The CNAME records in the _msdcs portion of the forest root zone identify the DCs in the forest. You can end up in a Catch-22 situation where a forest root DC canít find the CNAME record for a replication partner and canít get a copy of the CNAME record because it canít replicate. Windows Server 2003 resolves this problem by automatically going to another DNS server if it canít find the CNAME record corresponding to a DC GUID in AD.

Donít Forget the People
All of the problems and errors listed in this article can be avoided by planning and testing. Thereís a final problem, though, that transcends technology. Itís a people issue.

In many organizations, the need to support AD in DNS puts the Windows folks in the same meeting room with the Unix folks who control the existing DNS servers. Sometimes those meetings achieve spectacular results. The participants use their long history of mutual trust to share insights into their own needs and requirements and, in doing so, they create a design that incorporates all the best features of Windows DNS and BIND or VitalQIP or DNS Commander, or whatever flavor of DNS is running on the Unix servers.

Other times, the results of the meetings arenít quite so collegial.

As you work for a compromise that allows you to mix different versions of DNS in the same organization, keep these words of Doug Floyd from Spokaneís The Spokesman-Review in mind: ďYou donít get harmony if everyone sings the same note.Ē

Primary Computer Service, Inc.
Copyright © 2016 [Primary Computer Service, Inc]. All rights reserved.
Revised: 05/07/18