Always remember that there are two sides to DNS. Firstly, registration which adds resource records
such as Host (A) into the DNS database. Secondly there are queries where clients
seek those resource records, for example where is BigServer? Back comes
the reply from DNS: BigServer IP = 10.10.55.21.
The goal of a DNS query is to find an authoritative DNS server, which can then return the IP address for the queried host. Authoritative DNS Servers have ownership and knowledge about resource records for a particular domain. From the point of view of a query, contacting Authoritative server is good news because you get an
instant response of an IP address, or a host not found error message. However, if that server was not authoritative then, as we will see, DNS turns to forwarders, iterative queries and root
hints.
To check which DNS servers are authoritative, select the Forward Lookup Zone, domain name, properties and then Start of Authority (Tab), finally Primary Server:
Technically, DNS queries divide into two sub types, recursive or iterative.
Whereas I a normally like to savour and remember terms, this pair don't help
that much in understanding DNS. In practical terms a good DNS uses both methods to resolve the query and again from a practical point of view the best thing you can do is make sure the 'Root Hints' are
set correctly on the server and the firewall.
Recursive Query
Recursive is the simpler query of the pair to understand in that its all or nothing. The DNS server either returns the full answer or a 'server not found' error. A recursive query is the type of
name resolution that an XP client may send to its DNS server. If the server knows the answer to the query, then no problem, however if the DNS
server does not know the answer then takes up the search on behalf of the client.
Consider an example where an XP client in yourdomain.com says to its DNS server: '
Give me the IP address of webserver.microsoft.com.'
Your server could respond to the effect, 'I am not authoritative for microsoft.com - go away'.
This would come back as an official reply: 'server not found'. More likely, your server would take up the search on behalf of the client. What would happen is that the server queries the root hints
in an attempt to find the whereabouts of the microsoft.com domain servers. The key difference between a recursive and iterative request is that the server does all the work on behalf of the client.
Iterative Query
An iterative
Query is usually conversations between DNS Servers, whereas a recursive query is usually a client asking a DNS server for name resolution.
What happens with an iterative query is that the requesting
server 'steps' the DNS root hints. It says to the root servers, ' Where is Microsoft.com?' If this was a recursive query, then the root server would say 'I don't know, server not found'. But with an iterative
query the root server gives its best shot and says, 'Try the .com servers at w.x.y.z. IP address'. Then the .com server would iteratively point your DNS to microsoft.com
and as Microsoft would be authoritative for web.microsoft.com, at last, back comes the IP address. This 'stepping'
the root hints is known as an iterative query. The key difference is that a server can respond to an iterative query with a partial reply. With luck, this partial reply will be a
stepping stone to finding the Fully Qualified Domain Name.
Guy Recommends: A Free Trial of the Network Performance Monitor
(NPM)
SolarWinds'
Network Performance Monitor
will help you discover what's happening on your network. This
utility will also guide you through troubleshooting; the dashboard will
indicate whether the root cause is a broken link, faulty equipment or
resource overload.
Perhaps the NPM's best feature is the way it suggests solutions to network
problems. Its second best feature is the ability to monitor the health of individual VMware
virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you
give this Network Performance Monitor a try.
If your Windows DNS server is connected to the internet and your clients want to find websites, then you need to check your root hints. The good news is that Root Hints are installed be default.
What Root Hints do is act as pointers to servers that know the IP address of the top level domains. Launch your DNS Snap-in, select the Server Icon, right-click select Properties and then select the Root
Hints tab.
Root hints are stored in a physical file called cache.dns. You can
inspect this file in the
%systemroot%\windows32\dns\samples folder.
Here is what cache.dns looks like
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
These NS records of the ' . ' root servers are loaded into the Root Hint tab of your DNS server.
Test your forward and reverse lookups by clicking on the Monitoring Tab visible from your server properties. You may also be
able to see the Monitoring Tab on the above diagram.
DNS Servers build up a cache of previously resolved queries. As requests are looked up on other
servers, so records are added to the cache. A good cache has the twin benefits of faster response time and less network traffic. A bad cache can be a liability in that it gives the requestor incorrect
information. One reason that I like to set the DNS snap-in to View, Advanced is that I can then see which records are in the Cached Lookups folder. Another reason that I like to view the Cached
Lookups folder is so that when I am troubleshooting, I can right-click the folder and Clear Cache.
Small sites sometimes manage DNS through caching only servers, the point is that the learn, and cache
records the few users need but as they have no Zones themselves, their is no associated replication traffic. This technique is useful where you have Active Directory Integrated zones and want a DNS server
which is not a domain controller.
Calculating IP Address ranges is a black art, which many network managers
solve by creating custom Excel spreadsheets. IPAT cracks this problem of
allocating IP addresses in networks in two ways:
For Mr Organized there is a nifty subnet calculator, you enter the network
address and the subnet mask, then IPAT works out the usable addresses and their
ranges. For Mr Lazy IPAT discovers and then displays the IP addresses of existing
computers.
Forwarder by name, forwarder by nature. The situation is that when your DNS
server receives a query, for which it is not authoritative, it contacts a server that
does know the answer to that query. Moreover, instead of 'walking' the root hints, it
refers directly to a server that has the appropriate resource records.
Secondary zones contacting their primary zone would be an example of forwarders.
One major use of Forwarders is for networks which use firewalls, perimeter
networks or DMZ (demilitarised zone. For security reasons, the internal
DNS servers know nothing of the internet root hints, so they forward all such
queries to severs on the internet facing side of the firewall or perimeter
network.
Conditional Forwarding
Another classic use of forwards is where companies have subsidiaries,
partners or people they know and contact regularly query. Instead of going the
long-way around using the root hints, the network administrators configure
Conditional Forwarders.
The clever idea with conditional forwarders is that only certain namespaces
are forwarded to particular servers. If you have a subsidiary called
Acme.com, then you could configure all queries for Acme.com to their DNS
servers, while other queries could go out to the internet via the root hints. See more on conditional forwarding
When configuring or troubleshooting DNS, start by asking: 'Is this a
registration problem, or is this a query problem? DNS queries invariably involve many
steps. If you clients are experiencing problems, then check the DNS Server Properties, in particular examine the root hints
and the forwarders tabs.
If you like this page then please share it with your friends
Guy Recommends:
SolarWinds' NPM - Network Performance Monitor
SolarWinds' performance monitor is designed for detecting network outages,
making it easy to see what's working, and what needs your attention.
This utility guides you through creating network maps; it also helps
identifying whether the
root cause is faulty equipment, or resource overload. Give NPM a try.
Test your forward and reverse lookups by clicking on the Monitoring Tab visible from your server properties. You may also be
able to see the Monitoring Tab on the above diagram.
