Again, hello everyone!
This time I am bring enlightenment... But before I begin, let me answer an
earlier post.
Check the registry pointer. I remember Mark Russinovich, in one of his blogs,
griping about naming conventions used by XP64, when switching in and out of
64 bit mode.
Ah, you mean the SysInternals guy(s), yep. I posted on their forum first,
but did not get much of a response. But thanks for the reference.
There are several Microsoft addresses that are ignored by Windows XP, for
"security" reasons, including shite like msn.com. Microsoft has circumvented
hosts use selectively. This article is from a couple months ago.
http://comments.gmane.org/gmane.comp.security.full-disclosure/43878
Is that so... well, well, thats just bad form.
You could use something like eDexter or Hostsman to read Hosts from its
current location. Make sure you know where Hosts is.
The location was/is fine.
I came across dexter on my initial google wonderings... The only thing of
interest
there, was that they mentioned I should turn the dnsclient process off. I
already
got that from wikipedia, so nothing new. But I was not satisfied with the
answer.
That's what I've been told to do - and what I advise everybody else. If you
don't have a real DNS server on your LAN (and this does not include a DNS relay
on your NAT router), leave the DNS service off.
The questions is... BUT WHY? Sheesh (I feel like a little kid again)
Quoting my nice shiny new "Microsoft Windows Server 2003 TCP/IP
Implementation Details" documentation:
"Windows Server 2003 includes a DNS caching resolver service. This service
performs the function of caching DNR answers so that the DNS
server does not need to be repeatedly queried for the same information."
For me the idea is pretty simple:
The bigger the cost of dns hit; the bigger the saving, if the entry is in
the cache. Why would you turn it off for remote dns and on for local only. It
would seem most logical if you turned it on for remote, and off for local dns
server (which probably has a cache anyway for holding replies from upstream
queries... the one I use under Free BSD does). However, perhaps the cache
only works reliably for quick responding, relatively reliable (i.e. local)
DNS server. If that is the case then it is a shame (or should it be sham). An
aside, if your dns server requests are timing out when the services are
actually still alive, why don't you crank up the time out values and give
your client a nice long (or at least an appropriate) time to fail. You can
find the registery key names in the docs in appendix C. Thanks Daniel for the
ref:
www.microsoft.com/downloads/details.aspx?familyid=06C60BFE-4D37-4F50-8587-8B68D32FA6EE&displaylang=en
That WikiPedia reference is a bit whack. XP does NOT ignore the Hosts file -
that's why I disable my DNS Client - it takes forever to load when it's big. I
wish whoever wrote that had included a link to that article. WikiPedia is good
for tutorials (but check each link periodically), but I would not use them for a
single definitive reference.
I agree completely with you. It did give me a good starting point and gave
me the first clue as to where I should look for the real problem. Indeed XP
does not ignore the hosts file, but the resolver may not be able to read it!
But I am getting ahead of myself.
Let the story continue...
Ok, So after I slept on the problem I decided I would be rather pragmatic
and tackle this problem like any good developer. I headed over to
www.sysinternals.com and grabbed a copy of Regmon and Filemon. If you are
having similar problems, these ARE THE "DEBUGGING" TOOLS you need. You will
need to figure out what to filter out with these programs otherwise you will
"not see the wood from trees".
There are definitly some interresting registry entries which get looked for
when the dns client starts, some of which are NOT listed in Appendix C of
above mentioned document (surprise!):
If you look in regmon, you will see a portion of the log looking something
like this:
OpenKey HKLM\Software\Policies\Microsoft\Windows NT\DnsClient NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\QueryAdapterName NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DisableAdapterDomainName NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\UseDomainNameDevolution NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\UseDomainNameDevolution SUCCESS 0x1
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\PrioritizeRecordData NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\PrioritizeRecordData NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\AllowUnqualifiedQuery NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\AllowUnqualifiedQuery NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\AppendToMultiLabelName NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\ScreenBadTlds NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\ScreenUnreachableServers NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\FilterClusterIp
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\WaitForNameErrorOnAll
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\UseEdns NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\QueryIpMatching NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\UseHostsFile NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\RegistrationEnabled NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DisableDynamicUpdate NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\RegisterPrimaryName NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\RegisterAdapterName NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\EnableAdapterDomainNameRegistration NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\RegisterReverseLookup NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DisableReverseAddressRegistrations NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\RegisterWanAdapters NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DisableWanDynamicUpdate NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\RegistrationTtl NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationTTL NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\RegistrationRefreshInterval NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationRefreshInterval NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\RegistrationMaxAddressCount NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\MaxNumberOfAddressesToRegister NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\UpdateSecurityLevel NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\UpdateSecurityLevel NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\UpdateZoneExcludeFile NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\UpdateTopLevelDomainZones NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\DnsTest NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\MaxCacheSize NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\MaxCacheTtl NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\MaxNegativeCacheTtl NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\AdapterTimeoutLimit NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\ServerPriorityTimeLimit NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\MaxCachedSockets NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\MulticastListenLevel NOT FOUND
QueryValue HKLM\System\CurrentControlSet\Services\DnsCache\Parameters\MulticastSendLevel NOT FOUND
Clearly if the value is not found in the registry the app uses the default.
I never got as far as disassembling the DLL to learn the
defaults (if you care, the dll is located here:
%SystemRoot%\System32\DNSRSLVR.DLL), because I found my problem before I
reached that stage. This is also not all of the registry activity but its the
bulk of the interesting activity. Something that did catch my eye immediatly
was the entry: UseHostsFile (aprox #15 above). I added this value as a DWORD
entry to the registry and fiddled with this value for a bit. I may have been
tweaking the value in the wrong control set (silly me), so I will leave the
functionality as inconclusive. On another machine where everything was
working, this value was missing (as above) so I did not investigate further.
Enter Filemon...
Filemon reported that the file %SystemRoot%\System32\dnsrslvr.log was being
opened and failing because it did not exist. I created the file and added the
user: NETWORK SERVICES to the list of user under the security tab and then
gave write permission to this user.
Restarted the server... and hey presto, LOGGING FOR THE DNS CLIENT SERVICE
(Be sure to delete this file when you are done with your debugging). One
thing that I did find strange was that there was no read activity against the
hosts file. As it turns out the service watches the
%SystemRoot%\System32\drivers\etc folder (the folder's internal data contains
information for the sub files/folders) and then when it sees a change on the
hosts file it does its thing - it flushes the dns cache and rereads the hosts
file (as promissed by the docs). This was all reported in the log file. The
log always reported 0 records read. I deleted all the contents and added the
standard 1
line'r, 127.0.0.1 localhost, still no records. Filemon also reported that
some programs would make direct reads against the hosts file and where
monitoring it themselves (firefox for example... interesting!)
In the Filemon log one entry, hidden between masses of activity, finally
gave me the source problem:
OPEN C:\WINDOWS\system32\drivers\etc\hosts ACCESS DENIED NT
AUTHORITY\NETWORK SERVICE
So I added this user to the security tab (with READ ONLY access)
Restarted the service... PROBLEM SOLVED.
The problem may have been my own doing, I might have copied the hosts file
(and the default file permissions) from another machine. I don't remember...
I probably did that 2 weeks or so back while setting up the VPN. Ah well,
live and learn.
Right, so to explain the initial behaviour I reported, in which I thought
the dns client was ignoring the hosts file:
When you switch off the dnsclient, any software resolving domain names goes
directly to the hosts file via the sockets library The process accesses the
file as the user the process is running as, so no problem with read
permission. When the dnsclient is active software resolves via it, its
running as a different user and has the read failure problem I discovered.
Probably the biggest fault is that the problem is not announced (Microsoft:
an event entry would be a good thing here).
(Something to laugh about: On XP 64bit as a non admin user if I double click
on the clock in the task try to see the calender, I get an information dialog
box: "You do not have the proper privlege level to change the System Time"...
nice! At least they are reporting it, though a read only option would be
good... *chuckle*, this is realeased software, I wonder if vista will ever
get out of the door)
Some other comments:
The cache has a limited size (registry settings MaxCacheSize, etc). So if
you are using the dnsclient your rather large hosts file will be truncated
and records thrown out over time for more frequently used records (hey thats
the way caching works), this will explain why some of the host entries are
being ignored and causing all this concern from certain individuals. The fact
that it does not reread the hosts file every name resolve request, if the
entires do not all fit, is an efficiency concern and probably implemented to
avoid it. Think about it.
Ok: Now onto your mega hosts file. If the dns client process takes a long
time to read it, your file is probably causing problems with other programs
when they resolve initially too, your just not noticing it becuase it being
amortised with other system activity (though that would be an educated
guess). Maybe the socket library is relatively smart about caching the
complete file (it been around long enough - these things get refined). The
hosts file was not intended to be used for security purposes, text look ups
are definitly not efficient for 250K files... but its your choice.
Cheers
Caleb