DNS cache and hosts file ignored

[Guest]

Hello everyone,

I have a nice new installation of Window XP Pro 64. SP 1 (v2003).
My problem can be stated rather simply as: My hosts file is being completely
ignored by the DNS client.

The Hosts file is valid (name and content) and located in the correct
folders. The registery settings are correctly set to find the hosts file. I
have read the tech manuels on Microsofts web site looking for any hidden
gotchas. Nothing strange there, and indeed they reflect my understand of how
my domain names should be resolved

Here are some links to the resource I have been using

http://www.microsoft.com/technet/itsolutions/network/deploy/
depovg/tcpip2k.mspx
http://www.microsoft.com/technet/itsolutions/network/evaluat
e/technol/tcpipfund/tcpipfund_ch07.mspx

Right, so now I will draw your attention to the following text from the
above resource (give or take some typos):

This file maps host names to IP addresses. For TCP/IP for Windows XP and
Windows Server 2003, the contents of the Hosts file are loaded into the DNS
client resolver cache.

And then then a little further down some comments about the dns client
resolver are made, which I have summerised/hacked out as follows:

The DNS Client Resolver Cache

The DNS client resolver cache stores entries for both successful and
unsuccessful DNS name resolutions.

* The contents of the cache are built dynamically from the Hosts file
and from DNS queries.
* DNS query entries are kept only for the Time to Live (TTL) period.
* Hosts file entries do not have a TTL and are kept until the entry is
removed from the Hosts file.

The ipconfig /displaydns command can be used to view the contents of the DNS
client resolver cache and ipconfig /flushdns flushes the cache and refreshes
the DNS client resolver cache with just the entries in the Hosts file.

The documenation is quite clear. I flushed the cache and then listed the
contents on the 64 bit PC. The cache was empty. I did the same thing on
another machine, and their the cache contained the hosts file, as promised.

After some more googling I came across a wikipedia entry which stated the
following (give or take a few edits):

Windows XP SP2, and perhaps other versions, appears to ignore the hosts file
if the "DNS Client" service is running. One workaround is to stop the DNS
Cache service. To preserve this setting across reboots ensure that the
service is reconfigured to start manually. (Being a good sport, I added some
text to the entry)

The strange thing is that the 2nd machine I tested on, is an XP SP2
installation... Further, when I turn off this service as suggested, my hosts
file works as expected.

So the question is what is going on here? Is this a bug? Or am I missing
some magic settings that will make dns caching read the hosts file as
promissed in the docs?

When I searched the forum for similar topics I read that some one had the
reverse problem. i.e. when the cache was turned off resolving failed. Which
make sense to me... go figure.

Any ideas?

 

[POSITRON]

Hello everyone,

I have a nice new installation of Window XP Pro 64. SP 1 (v2003).
My problem can be stated rather simply as: My hosts file is being completely
ignored by the DNS client.

The Hosts file is valid (name and content) and located in the correct
folders. The registery settings are correctly set to find the hosts file. I
have read the tech manuels on Microsofts web site looking for any hidden
gotchas. Nothing strange there, and indeed they reflect my understand of how
my domain names should be resolved

Here are some links to the resource I have been using

http://www.microsoft.com/technet/itsolutions/network/deploy/
depovg/tcpip2k.mspx
http://www.microsoft.com/technet/itsolutions/network/evaluat
e/technol/tcpipfund/tcpipfund_ch07.mspx

Right, so now I will draw your attention to the following text from the
above resource (give or take some typos):

This file maps host names to IP addresses. For TCP/IP for Windows XP and
Windows Server 2003, the contents of the Hosts file are loaded into the DNS
client resolver cache.

And then then a little further down some comments about the dns client
resolver are made, which I have summerised/hacked out as follows:

The DNS Client Resolver Cache

The DNS client resolver cache stores entries for both successful and
unsuccessful DNS name resolutions.

* The contents of the cache are built dynamically from the Hosts file
and from DNS queries.
* DNS query entries are kept only for the Time to Live (TTL) period.
* Hosts file entries do not have a TTL and are kept until the entry is
removed from the Hosts file.

The ipconfig /displaydns command can be used to view the contents of the DNS
client resolver cache and ipconfig /flushdns flushes the cache and refreshes
the DNS client resolver cache with just the entries in the Hosts file.

The documenation is quite clear. I flushed the cache and then listed the
contents on the 64 bit PC. The cache was empty. I did the same thing on
another machine, and their the cache contained the hosts file, as promised.

After some more googling I came across a wikipedia entry which stated the
following (give or take a few edits):

Windows XP SP2, and perhaps other versions, appears to ignore the hosts file
if the "DNS Client" service is running. One workaround is to stop the DNS
Cache service. To preserve this setting across reboots ensure that the
service is reconfigured to start manually. (Being a good sport, I added some
text to the entry)

The strange thing is that the 2nd machine I tested on, is an XP SP2
installation... Further, when I turn off this service as suggested, my hosts
file works as expected.

So the question is what is going on here? Is this a bug? Or am I missing
some magic settings that will make dns caching read the hosts file as
promissed in the docs?

When I searched the forum for similar topics I read that some one had the
reverse problem. i.e. when the cache was turned off resolving failed. Which
make sense to me... go figure.

Any ideas?

I love the detail you have provided here. You did better research than
I did. I gave up with my Windows XP HOME / SP2 because I could not
verify the accuracy of the explanation as above. Indeed, I cam to a
strange, unverified conclusion...
There is hook, perhaps because of a Microsoft business relationship with
some advertisers. There are DNS entries that I can never get rid of. I
will list them at the end of this post. I also find that Windows XP
systems located in different cities may produce different results.

Even thought I have filtered these domains in my HOSTS file, they still
function. Hmmmm. Is there a business agreement involved here?

I have a 250K HOSTS file. I redirect to my own web server to handle
those domains appropriately (Kill their intended function). Why is my
hosts file not in the list created by
ipconfig /displaydns ?

Likewise, I cant flush it.

Where did this unwanted data come from?
Why is it permanent?
Is it perhaps hard coded or otherwise provided by the DNS client service?

.... Ask Bill G.

(If I stop service DNS Client,
ipconfig /displaydns produces message
"Windows IP Configuration

Could not display the DNS Resolver Cache."

Maybe XP Home is different? I doubt it.

HOSTS file IS working; it simply does not show in the DNS cache.

king-daddy


ipconfig /displaydns
Results...

ads.x10.com
----------------------------------------
Record Name . . . . . : ads.x10.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


www15.ad.tomshardware.com
----------------------------------------
Record Name . . . . . : www15.ad.tomshardware.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


rd.advertising.com
----------------------------------------
Record Name . . . . . : rd.advertising.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


us-nj-2.ns.nsatc.net
----------------------------------------
Record Name . . . . . : us-nj-2.ns.nsatc.net
Record Type . . . . . : 1
Time To Live . . . . : 1918
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 67.29.176.241


clickit.go2net.com
----------------------------------------
Record Name . . . . . : clickit.go2net.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


187.188.69.207.in-addr.arpa
----------------------------------------
Record Name . . . . . : 187.188.69.207.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : ns3.mindspring.com


f.abz.com
----------------------------------------
Record Name . . . . . : f.abz.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


ads.pennyweb.com
----------------------------------------
Record Name . . . . . : ads.pennyweb.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


www.clicksites.net
----------------------------------------
Record Name . . . . . : www.clicksites.net
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


www.paypopup.com
----------------------------------------
Record Name . . . . . : www.paypopup.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


www.ourmagicbox.com
----------------------------------------
Record Name . . . . . : www.ourmagicbox.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88


servedby.advertising.com
----------------------------------------
Record Name . . . . . : servedby.advertising.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer

Here is the result

 

[Daniel Crichton]

Caleb wrote on Fri, 2 Jun 2006 05:41:02 -0700:

I have a nice new installation of Window XP Pro 64. SP 1 (v2003).
My problem can be stated rather simply as: My hosts file is being
completely
ignored by the DNS client.

The Hosts file is valid (name and content) and located in the correct
folders. The registery settings are correctly set to find the hosts file.

Exactly what location is it in? I haven't messed with XP 64 yet, but maybe
it should be in

c:\windows\system64\drivers\etc\

rather than the system32 folder - if XP 64 has a system64 folder.

I have read the tech manuels on Microsofts web site looking for any hidden
gotchas. Nothing strange there, and indeed they reflect my understand of
how my domain names should be resolved

Here are some links to the resource I have been using

http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx

This is for Windows 2000, not XP, and so some aspects may well have changed.
Download the article for Windows 2003 from
tp://www.microsoft.com/downloads/details.aspx?familyid=06C60BFE-4D37-4F50-8587-8B68D32FA6EE&displaylang=en
- this includes the XP implementation details.

The documenation is quite clear. I flushed the cache and then listed the
contents on the 64 bit PC. The cache was empty. I did the same thing on
another machine, and their the cache contained the hosts file, as
promised.

This points to XP 64 either not loading the hosts file due to an error on
one of the lines, or it being in the wrong location.

After some more googling I came across a wikipedia entry which stated the
following (give or take a few edits):

Windows XP SP2, and perhaps other versions, appears to ignore the hosts
file if the "DNS Client" service is running. One workaround is to stop the
DNS Cache service. To preserve this setting across reboots ensure that the
service is reconfigured to start manually. (Being a good sport, I added
some text to the entry)

I disable the DNS Client service on the systems here as I've found it has a
habit of getting "stuck", at least on 2000 - if the primary DNS server
doesn't respond to a request it kicks to the secondary, and from then on
only uses the secondary. On occassion I've had DNS resolution fail
completely when the secondary didn't respond quickly, and the machines
didn't return to trying the primary.

Dan

 

[Chuck]

Caleb wrote on Fri, 2 Jun 2006 05:41:02 -0700:


Exactly what location is it in? I haven't messed with XP 64 yet, but maybe
it should be in

c:\windows\system64\drivers\etc\

rather than the system32 folder - if XP 64 has a system64 folder.

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.

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>
http://comments.gmane.org/gmane.comp.security.full-disclosure/43878

You could use something like eDexter or Hostsman to read Hosts from its current
location. Make sure you know where Hosts is.
<http://accs-net.com/hosts/eDexter.html>
http://accs-net.com/hosts/eDexter.html

This is for Windows 2000, not XP, and so some aspects may well have changed.
Download the article for Windows 2003 from
tp://www.microsoft.com/downloads/details.aspx?familyid=06C60BFE-4D37-4F50-8587-8B68D32FA6EE&displaylang=en
- this includes the XP implementation details.


This points to XP 64 either not loading the hosts file due to an error on
one of the lines, or it being in the wrong location.


I disable the DNS Client service on the systems here as I've found it has a
habit of getting "stuck", at least on 2000 - if the primary DNS server
doesn't respond to a request it kicks to the secondary, and from then on
only uses the secondary. On occassion I've had DNS resolution fail
completely when the secondary didn't respond quickly, and the machines
didn't return to trying the primary.

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.

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.

 

[Daniel Crichton]

Chuck wrote on Fri, 02 Jun 2006 07:56:44 -0700:

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.

I have it left off even using mutiple DNS servers on my LAN. I'd rather have
100% name resolution rather than the mess that sometimes appears when the
DNS Client service is running.

Dan

 

[Guest]

I have a 250K HOSTS file. I redirect to my own web server to handle

those domains appropriately (Kill their intended function). Why is my
hosts file not in the list created by

Personally I just use firefox with the ad blocking extension...

ipconfig /displaydns ?
Likewise, I cant flush it.

Where did this unwanted data come from?

This is a good question...

Why is it permanent?

Is it? Out of curiousity, do a little experiment for me... Try unplugging
your network card and flushing the cache. If the values get filled with
negative hits, it means something on your machine is sending dns resolution
requests for these domains. The time to live value should not be there for
hard coded values.... Of course this assumption is based on what I read in
the documentation.

I would like here what your results are... Let see how evil they can be :-D

ipconfig /displaydns
Results...

ads.x10.com
----------------------------------------
Record Name . . . . . : ads.x10.com
Record Type . . . . . : 1
Time To Live . . . . : 398002
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 24.136.140.88

....<SNIP>....

 

[Richard G. Harper]

The IP address shown by all these entries is almost surely your ISP's DNS
server, since it comes back to mindspring.com - is that your ISP? The names
of the entities almost surely are servers and services you're connected to
at the time you run the query.

I'd reboot the PC, then before even firing up a single program, email or
browser, run the test again. I'll bet you see vastly different results.

--
Richard G. Harper [MVP Shell/User] (e-mail address removed)
* PLEASE post all messages and replies in the newsgroups
* for the benefit of all. Private mail is usually not replied to.
* My website, such as it is ... http://rgharper.mvps.org/
* HELP us help YOU ... http://www.dts-l.org/goodpost.htm

 

[POSITRON]

Personally I just use firefox with the ad blocking extension...


This is a good question...

Is it? Out of curiousity, do a little experiment for me... Try unplugging
your network card and flushing the cache. If the values get filled with
negative hits, it means something on your machine is sending dns resolution
requests for these domains. The time to live value should not be there for
hard coded values.... Of course this assumption is based on what I read in
the documentation.

I would like here what your results are... Let see how evil they can be :-D


...<SNIP>....

After flush:
Successfully flushed the DNS Resolver Cache.

Without reconnecting the network card,
ipconfig /displaydns
gets the same results. It did not flush
<frown>

 

[POSITRON]

The IP address shown by all these entries is almost surely your ISP's DNS
server, since it comes back to mindspring.com - is that your ISP? The names
of the entities almost surely are servers and services you're connected to
at the time you run the query.

I'd reboot the PC, then before even firing up a single program, email or
browser, run the test again. I'll bet you see vastly different results.

The IP address is that of MY machine's LINKSYS router (my gateway)
connected to the cable modem. I had not noticed that.
I am on earthlink which owns mindspring.

king-daddy

 

[POSITRON]

The IP address is that of MY machine's LINKSYS router (my gateway)
connected to the cable modem. I had not noticed that.
I am on earthlink which owns mindspring.

king-daddy

FYI:
Following up,
I find all those addresses in my HOSYS file, but not in any sensible
organization. Most of them are in the first 50 or so, but one is from
the middle of this huge HOSTS file.

I tried adding 3 new entries to HOSTS. The ones displayed did not change.

I tried removing several lines. The display did not change.

king-daddy

 

[Guest]

Exactly what location is it in?

The registry entry and file location are: %SystemRoot%\System32\drivers\etc

(The registry key type is correct too... REG_EXPAND_SZ, and just to be
pedantic the keys name is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DataBasePath)

I haven't messed with XP 64 yet, but maybe
it should be in c:\windows\system64\drivers\etc\

rather than the system32 folder - if XP 64 has a system64 folder.

Yes, I had though of that too... I even considered that 32 bit apps would
use the hosts file mentioned above and 64 bit apps would use something else,
but thats just a stab in the dark. I am no 64bit XP Guru, but I think the 64
bit system files fall under the folder:

%SystemRoot%\SysWOW64

There is an etc folder in there and it is empty
(%SystemRoot%\SysWOW64\Drivers\etc). I have tried copying the hosts file into
it, and it made no difference. Perhaps there is another (missing) registry
entry.

http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx

This is for Windows 2000, not XP, and so some aspects may well have changed.
Download the article for Windows 2003 from
tp://www.microsoft.com/downloads/details.aspx?familyid=06C60BFE-4D37-4F50-8587-8B68D32FA6EE&displaylang=en
- this includes the XP implementation details.

Yes, I was aware that it was for 2000. But I was thinking XP was born from
2000. But your comment reminds me that XP-64 originated from 2003... so I
will give those docs a read through... Ok I gave the relavent sections and
appendix C a read through, I did not read anything startling ... no ah ha!
There it is.... But thanks for the reference anyway (neat document).

This points to XP 64 either not loading the hosts file due to an error on
one of the lines, or it being in the wrong location.

That is the conclusion I came to too, that is why I asked for the "magic
setting". The hosts file is valid (100% sure), I have worked with hosts files
often enough. In addition the machine reads the file and resolves properly
when I switch the dns client service off.

I disable the DNS Client service on the systems here as I've found it has a
habit of getting "stuck", at least on 2000 - if the primary DNS server
doesn't respond to a request it kicks to the secondary, and from then on
only uses the secondary. On occassion I've had DNS resolution fail
completely when the secondary didn't respond quickly, and the machines
didn't return to trying the primary.

Hmmm, thats interesting. Good to know.
WRT the document you listed above you can change various timeouts to be more
"patient". Might also solve these problems.

Thanks for the feedback.

Cheers
Caleb.

 

[Guest]

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.

http://accs-net.com/hosts/eDexter.html

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