Failed to find nameservers of notageek.biz/IN
No nameservers found at child.
Solution: restart the nameserver
restart the switch between nameserver and
*** 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
Site won't load without "WWW"
- Zone must have a forward entry without the "www" -> host A
(same as parent folder)
- Zone must have a reverse entry without the "www
- 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 west.school.edu 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 west.school. edu
domain wonít find a host in the east.school.edu 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
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.
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
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 www.isc.org.
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 @w2k3-dc1.school.edu school.edu ifxr=87
; <>> DiG 9.2.3 <>> @192.168.0.250 school.edu ixfr=89
;; global options: printcmd
www.school.edu. 3600 IN CNAME webserver2.school.edu.
school.edu. 3600 IN SOA w2k3-dc1.school.edu. hostmaster.school.edu. 90 900 600
This listing shows the SOA and a CNAME record called www.school.com that points
at a server named webserver2.school.edu.
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
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 /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
DNS Management Console
Figure 4. The DNS management console showing CNAME records for DCs in an AD
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 download.microsoft.com/
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
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
www.deviousdomain.com. It finds the name server for deviousdomain.com 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 Microsoft.com, Yahoo.com
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
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
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 www.dnssec.org/rfc.php.
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
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
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
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
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
Primary Computer Service, Inc.
Copyright © 2016 [Primary Computer Service,
Inc]. All rights reserved.