Arun Kumar | Senior Support Engineer
When viewing the Local Resolution Time monitor in the DNS Management Pack for Operations Manager, you may notice that the response time reported does not reflect your own real world results. For example, I recently worked with a customer where the Local Resolution Time view under Performance showed around 12 seconds as the response time for the DNS servers even though the response times actually observed were almost instantaneous.
In the above screen shot you can see the response time was shown to be around 12 seconds except for a little portion at the end where is it showed a response time of essentially 0. However, when we run nslookup and resolve a name, the DNS server in question would respond immediately to all queries. So where are we getting this 12 seconds response time from? Let me give you a little background on how this works and later I will talk about the cause of this behavior.
Collect local resolution time is the rule that collects this information from the DNS servers and by default this rule runs once every 15 minutes. There isn’t much detail concerning how exactly it’s trying to get the data in the rule itself but if you go through the DNS management pack guide it mentions the scripts that are used. The script that is used for this rule is Nslookupalltest.js.
To see how this script is used, I took diagnostic tracing (see KB942864 - How to use diagnostic tracing in System Center Operations Manager 2007 and in System Center Essentials) and went through the TracingGuidsScript.log file that was created. By doing so we found that the script was being run with the following parameters:
cscript.exe with command line '"C:\Windows\system32\cscript.exe" /nologo "NslookupAllTests.js" "dc1.contoso.com" "192.168.100.101,fe80::1452:6556:3ba0:6465" "a" "false" "none" "360" "2" "false"
I then ran the same command manually on the DNS server in question and found the following information:
< Property Name="SuccessCount" VariantType="3">2
< Property Name="NonAuthoritativeCount" VariantType="3">2
< Property Name="FailureCount" VariantType="3">0
< Property Name="BestHost" VariantType="8">dc1.contoso.com
< Property Name="BestServer" VariantType="8">192.168.100.101>> Here we query the IPv4 address of the DNS
< Property Name="WorstHost" VariantType="8">dc1.contoso.com
< Property Name="WorstServer" VariantType="8">fe80::1452:6556:3ba0:6465>> Now we query the IPv 6 address
< Property Name="WorstTime" VariantType="5">11.715>> Notice here that the time discovered is 11.715 seconds
< Property Name="FailingPairs" VariantType="8">
So the issue appears to be only when we are trying to resolve the name using the IPv6 address of the DNS server. So what is the delay when the name is resolved via the IPv6 address?
What happens is that the script queried for both the A record and the PTR record for the give name (e.g. dc1.contoso.com). This also goes through DNS client side devolution before the actual name is resolved. So when the A record and the PTR record of dc1.contoso.com is queried using the IPv4 address of the DNS server, we get a successful response for both the queries because the DNS server is configured with the respective forward and reverse lookup zones and both the zones have the necessary records.
On the contrary, when the script queried for the A and PTR records for the name dc1.contoso.com against the IPv6 address of the DNS server, the server was able to find the A record but was not able to find the IPv6 PTR record for the same because a reverse lookup zone had not been configured. Since the use of IPv6 is not very widespread yet, having no IPv6 reverse lookup zone is not uncommon.
And if you are wondering how the script knows to append the IPv6 address of the server in the command, go to the Server State view in the DNS management pack and select the server in question and see the detail view as shown in the dialog below. You should be able to see the listening IP addresses of the DNS server, and if you see the IPv6 address there then it will be used.
So how do we fix this so that our graph shows accurate response time? There are two ways of getting around this situation.
1. Configure the DNS service so that it listens only on the IPv4 address. To do this select “Only the following IP addresses:” in the dialog above and choose only the IPv4 address from the list.
Note that disabling IPv6 at the OS level is not recommended as there is no way for us to predict how this may effect your environment. Also, if IPv6 is disabled on Windows Vista, Windows Server 2008 and later versions, some components will not function as expected. See Support for IPv6 in Windows Server 2008 R2 and Windows 7 for more information.
2. The preferred fix for this is to create a reverse lookup zone as well as the associated PTR records on the DNS.
One last note: You can run into the same issue If you don’t have a reverse look up zone for the IPv4 address of the DNS server as well. This is not isolated to IPv6 but rather is a function of the lack of a proper reverse lookup zone on the DNS.
Arun Kumar | Senior Support Engineer | Microsoft GBS Management and Security Division
Get the latest System Center news onFacebookandTwitter:
System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
