Windows Update in DMZ with no DNS Server

At the company I work for, we do not allow DNS server resolution for machine
in the DMZ (protected by Firewall). So to allow Windows Update to function in
this setup, I had been able to create a local host file
(C:\winnt\system32\drivers\etc\hosts) that would resolve various windows
update host names and allow the feature to work. I found recently that this
workaround is no longer working on XP machines (possible 2000 as well) and I
am not sure if it is because Windows update is now V6 and things changed or
because MS implemented some steps to protect against viruses and no longer
allows a local hosts files to be used for windows update name resolution.

As mentioned above, I do not have access to DNS server and the DNS Client
Service is turned off. Originally, I thought that the Hosts files was not
being used at all for host name resolution, but after some troubleshooting I
discovered that just certain entries in the hosts file are being ignored. As
an example I could ping to resolve genuine.microsoft.com and
update.microsoft.com but whenever I ping update.microsoft.com or
windowsupdate.microsoft.com the response is always:

Ping request could not find host update.microsoft.com. Please check the name
and try again.

This response indicates that host name resolution is ignoring the local
Hosts entries for update.microsoft.com and windowsupdate.microsoft.com. Even
if I change the IP address to localhost (127.0.0.1) I get the same response.
I suspect that MS implemented some code to prevent a virus from redirecting
windowsupdate but could not find any reference to this in Google.

Does anyone on this list have a suggestion for me? In the meantime, it is
easy enought for me to apply the patches using a CD or thumdrive, but it
would be much more convenient if I could find a solution.

regards,
Brent
P.S. I have attached a sample of what my hosts file looks like for reference:

207.46.157.30 update.microsoft.com
207.46.157.30 update.microsoft.com.nsatc.net
206.24.192.221 download.windowsupdate.com
206.24.192.221 download.windowsupdate.com.c.footprint.net
131.107.115.28 crl.microsoft.com
131.107.115.28 cr1.microsoft.com
207.46.232.190 genuine.microsoft.com
207.46.19.30 www.microsoft.com
207.46.198.60 www.microsoft.com
207.46.18.94 www.windowsupdate.com
207.46.18.94 windowsupdate.microsoft.com
207.46.18.94 windowsupdate.microsoft.nsatc.net
207.46.134.126 v4.windowsupdate.microsoft.com
207.46.134.126 v4windowsupdate.microsoft.nsatc.net

"Brent" <> wrote in message
news:211C65F8-1326-404F-B1DA-...
> At the company I work for, we do not allow DNS server resolution for machine
> in the DMZ (protected by Firewall). So to allow Windows Update to function in
> this setup, I had been able to create a local host file
> (C:\winnt\system32\drivers\etc\hosts) that would resolve various windows
> update host names and allow the feature to work. I found recently that this
> workaround is no longer working on XP machines (possible 2000 as well) and I
> am not sure if it is because Windows update is now V6 and things changed or
> because MS implemented some steps to protect against viruses and no longer
> allows a local hosts files to be used for windows update name resolution.
>
> As mentioned above, I do not have access to DNS server and the DNS Client
> Service is turned off. Originally, I thought that the Hosts files was not
> being used at all for host name resolution, but after some troubleshooting I
> discovered that just certain entries in the hosts file are being ignored. As
> an example I could ping to resolve genuine.microsoft.com and
> update.microsoft.com but whenever I ping update.microsoft.com or
> windowsupdate.microsoft.com the response is always:
>
> Ping request could not find host update.microsoft.com. Please check the name
> and try again.
>
> This response indicates that host name resolution is ignoring the local
> Hosts entries for update.microsoft.com and windowsupdate.microsoft.com. Even
> if I change the IP address to localhost (127.0.0.1) I get the same response.
> I suspect that MS implemented some code to prevent a virus from redirecting
> windowsupdate but could not find any reference to this in Google.
>
> Does anyone on this list have a suggestion for me?


Trace the link and compare the same exchange when a real DNS
is allowed to be used.


> In the meantime, it is
> easy enought for me to apply the patches using a CD or thumdrive, but it
> would be much more convenient if I could find a solution.
>
> regards,
> Brent
> P.S. I have attached a sample of what my hosts file looks like for reference:


According to my nslookup some of these addresses may be obsolete.

>
> 207.46.157.30 update.microsoft.com
> 207.46.157.30 update.microsoft.com.nsatc.net
> 206.24.192.221 download.windowsupdate.com

<example>
Non-authoritative answer:
Name: download.windodwsupdate.com
Address: 66.118.136.67
</example>

> 206.24.192.221 download.windowsupdate.com.c.footprint.net
> 131.107.115.28 crl.microsoft.com
> 131.107.115.28 cr1.microsoft.com

Typo? Non-existent domain


> 207.46.232.190 genuine.microsoft.com
> 207.46.19.30 www.microsoft.com

No.

> 207.46.198.60 www.microsoft.com

No and see above.

<example>
Non-authoritative answer:
Name: lb1.www.ms.akadns.net
Addresses: 207.46.18.30, 207.46.198.30, 207.46.199.60, 207.46.20.60
207.46.199.30, 207.46.19.60, 207.46.225.60, 207.46.20.30
Aliases: www.microsoft.com, toggle.www.ms.akadns.net
g.www.ms.akadns.net
</example>


> 207.46.18.94 www.windowsupdate.com
> 207.46.18.94 windowsupdate.microsoft.com
> 207.46.18.94 windowsupdate.microsoft.nsatc.net
> 207.46.134.126 v4.windowsupdate.microsoft.com
> 207.46.134.126 v4windowsupdate.microsoft.nsatc.net

<example>
Name: v4windowsupdate.microsoft.nsatc.net
Addresses: 207.46.244.158, 207.46.244.190, 207.46.134.62
Aliases: v4.windowsupdate.microsoft.com
</example>


HTH

Robert Aldwinckle
---

These IPs do change and it appears to depend on the name server you use
however, even with updated IPs it will not work. The ping test shows that the
Hosts file is not used to resolve host to IP for certain host names - see my
original e-mail.
I will update the IPs and retest but I do not think this will help.
regards,
Brent
"Robert Aldwinckle" wrote:

> "Brent" <> wrote in message
> news:211C65F8-1326-404F-B1DA-...
> > At the company I work for, we do not allow DNS server resolution for machine
> > in the DMZ (protected by Firewall). So to allow Windows Update to function in
> > this setup, I had been able to create a local host file
> > (C:\winnt\system32\drivers\etc\hosts) that would resolve various windows
> > update host names and allow the feature to work. I found recently that this
> > workaround is no longer working on XP machines (possible 2000 as well) and I
> > am not sure if it is because Windows update is now V6 and things changed or
> > because MS implemented some steps to protect against viruses and no longer
> > allows a local hosts files to be used for windows update name resolution.
> >
> > As mentioned above, I do not have access to DNS server and the DNS Client
> > Service is turned off. Originally, I thought that the Hosts files was not
> > being used at all for host name resolution, but after some troubleshooting I
> > discovered that just certain entries in the hosts file are being ignored. As
> > an example I could ping to resolve genuine.microsoft.com and
> > update.microsoft.com but whenever I ping update.microsoft.com or
> > windowsupdate.microsoft.com the response is always:
> >
> > Ping request could not find host update.microsoft.com. Please check the name
> > and try again.
> >
> > This response indicates that host name resolution is ignoring the local
> > Hosts entries for update.microsoft.com and windowsupdate.microsoft.com. Even
> > if I change the IP address to localhost (127.0.0.1) I get the same response.
> > I suspect that MS implemented some code to prevent a virus from redirecting
> > windowsupdate but could not find any reference to this in Google.
> >
> > Does anyone on this list have a suggestion for me?
>
>
> Trace the link and compare the same exchange when a real DNS
> is allowed to be used.
>
>
> > In the meantime, it is
> > easy enought for me to apply the patches using a CD or thumdrive, but it
> > would be much more convenient if I could find a solution.
> >
> > regards,
> > Brent
> > P.S. I have attached a sample of what my hosts file looks like for reference:
>
>
> According to my nslookup some of these addresses may be obsolete.
>
> >
> > 207.46.157.30 update.microsoft.com
> > 207.46.157.30 update.microsoft.com.nsatc.net
> > 206.24.192.221 download.windowsupdate.com
>
> <example>
> Non-authoritative answer:
> Name: download.windodwsupdate.com
> Address: 66.118.136.67
> </example>
>
> > 206.24.192.221 download.windowsupdate.com.c.footprint.net
> > 131.107.115.28 crl.microsoft.com
> > 131.107.115.28 cr1.microsoft.com
>
> Typo? Non-existent domain
>
>
> > 207.46.232.190 genuine.microsoft.com
> > 207.46.19.30 www.microsoft.com
>
> No.
>
> > 207.46.198.60 www.microsoft.com
>
> No and see above.
>
> <example>
> Non-authoritative answer:
> Name: lb1.www.ms.akadns.net
> Addresses: 207.46.18.30, 207.46.198.30, 207.46.199.60, 207.46.20.60
> 207.46.199.30, 207.46.19.60, 207.46.225.60, 207.46.20.30
> Aliases: www.microsoft.com, toggle.www.ms.akadns.net
> g.www.ms.akadns.net
> </example>
>
>
> > 207.46.18.94 www.windowsupdate.com
> > 207.46.18.94 windowsupdate.microsoft.com
> > 207.46.18.94 windowsupdate.microsoft.nsatc.net
> > 207.46.134.126 v4.windowsupdate.microsoft.com
> > 207.46.134.126 v4windowsupdate.microsoft.nsatc.net
>
> <example>
> Name: v4windowsupdate.microsoft.nsatc.net
> Addresses: 207.46.244.158, 207.46.244.190, 207.46.134.62
> Aliases: v4.windowsupdate.microsoft.com
> </example>
>
>
> HTH
>
> Robert Aldwinckle
> ---
>
>
>

"Brent" <> wrote in message
news:EDFC2290-18B1-46EA-B866-
....
>>> after some troubleshooting I discovered that just certain entries
>>> in the hosts file are being ignored.


>> According to my nslookup some of these addresses may be obsolete.


> These IPs do change and it appears to depend on the name server you use
> however, even with updated IPs it will not work. The ping test shows that the
> Hosts file is not used to resolve host to IP for certain host names - see my
> original e-mail.


I saw that. I don't think that that symptom necessarily implies what you
are suggesting. I would like to see a packet trace of that exchange
to be really clear about what is happening. BTW unless you are certain
that duplicates in HOSTS are handled rationally I would like to see
the duplicate removed, especially since your problem entries follow it.


In fact, let's try telnet 80 as a better simulation of your problem scenario
and with better feedback. Here's what I get from

F:\>telnet 207.46.134.126 80

<example>

HTTP/1.1 302 Object moved
Date: Fri, 02 Sep 2005 22:06:23 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Location: /en/default.asp
Content-Length: 136
Content-Type: text/html
Cache-control: private

<head><title>Object moved</title></head>
<body><h1>Object Moved</h1>This object may be found <a HREF="/en/default.asp">here</a>.</bod
y>
</example>

That was giving the request GET / (GET<space><slash><Enter>)

and if I then re-establish that same connection and give it the request
GET /en/default.asp

I get much further.

What do you see if you try that on your problem machines?
How does it compare with what is actually happening with IE?
(It's not a perfect simulation by any means but a comparison
of the two traces should give a useful clue about what is wrong.)

Tip: XP Pro Support Tools provides netcap if you don't have any
other packet tracer for HTTP connections. You can browse the
resulting .cap file or format it with tools which can read and format
..cap files such as the freeware protocol analyser from Ethereal.


HTH

Robert
---

On Fri, 2 Sep 2005 18:38:57 -0400, "Robert Aldwinckle"
<> wrote:

>to be really clear about what is happening. BTW unless you are certain
>that duplicates in HOSTS are handled rationally I would like to see
>the duplicate removed, especially since your problem entries follow it.

Duplicates are a waste of space in a HOSTS file. The HOSTS file is
read top to bottom and reading stops upon the first match.
In this section of Brent's HOSTS file:

207.46.19.30 www.microsoft.com
207.46.198.60 www.microsoft.com

the second www.microsoft.com entry would NEVER be read.

--
dak
My SpywareBlaster Custom Blocking List:
<http://customblockinglist.cjb.net/>

"dak" <postmaster@[127.0.0.1]> wrote in message
news:...
> On Fri, 2 Sep 2005 18:38:57 -0400, "Robert Aldwinckle"
> <> wrote:
>
>>to be really clear about what is happening. BTW unless you are certain
>>that duplicates in HOSTS are handled rationally I would like to see
>>the duplicate removed, especially since your problem entries follow it.
>
> Duplicates are a waste of space in a HOSTS file. The HOSTS file is
> read top to bottom and reading stops upon the first match.
> In this section of Brent's HOSTS file:
>
> 207.46.19.30 www.microsoft.com
> 207.46.198.60 www.microsoft.com
>
> the second www.microsoft.com entry would NEVER be read.


That's what I would have guessed but my real concern was could
the presence of duplicates affect the scan of entries which follow them?

In any case I now notice that it's only one of the names he was having
trouble with which follows a duplicate.

BTW do you have an opinion on Brent's conjecture about those names?
Any better ideas for proving or disproving it?


Robert
---

On Sat, 3 Sep 2005 08:17:35 -0400, "Robert Aldwinckle"
<> wrote:

>>>to be really clear about what is happening. BTW unless you are certain
>>>that duplicates in HOSTS are handled rationally I would like to see
>>>the duplicate removed, especially since your problem entries follow it.
>>
>> Duplicates are a waste of space in a HOSTS file. The HOSTS file is
>> read top to bottom and reading stops upon the first match.
>> In this section of Brent's HOSTS file:
>>
>> 207.46.19.30 www.microsoft.com
>> 207.46.198.60 www.microsoft.com
>>
>> the second www.microsoft.com entry would NEVER be read.
>
>That's what I would have guessed but my real concern was could
>the presence of duplicates affect the scan of entries which follow them?
>
Not to my knowledge.

>In any case I now notice that it's only one of the names he was having
>trouble with which follows a duplicate.
>
>BTW do you have an opinion on Brent's conjecture about those names?
>
I have never heard of a HOSTS file's entries being used selectively.
Just a reminder that matches have to be exact, "www.microsoft.com"
and "microsoft.com" are not the same. It could be easy to overlook
any difference(s) in similar FQDNs.

>Any better ideas for proving or disproving it?
>
Sorry, no, but he might consider adding entries for V5 and V6 update
addresses, just in case. The only other thing I can think of is to
check the registry to ensure there is no redirection to another HOSTS
file, though that doesn't seem to be the case here.

--
dak
My SpywareBlaster Custom Blocking List:
<http://customblockinglist.cjb.net/>

"dak" <postmaster@[127.0.0.1]> wrote in message news:
....
>>Any better ideas for proving or disproving it?
>>
> Sorry, no, but he might consider adding entries for V5 and V6 update
> addresses, just in case. The only other thing I can think of is to
> check the registry to ensure there is no redirection to another HOSTS
> file, though that doesn't seem to be the case here.

Agreed. That's why I suggested a packet trace
but we still don't have an explanation for his counter-examples
using ping which I would also like to see traced.

I suppose I should trace ping myself sometime.
If it has the equivalent of an HTTP HOST: header
when a symbolic address has been given and that was
resulting in a redirect we would have an explanation
for that symptom too.


Robert
---

Robert and Dak,

I hope you are still following this thread - I had not been watching the
thread thinking that I would receive an e-mail notice if anyone sent in a
response. Thanks for your info but my issue remains unresolved. Here is a
some further detailed troubleshooting that I have performed.

1. I cleaned up the hosts file which now has no duplicates.
2. included in the hosts file is
207.46.18.94 windowsupdate.microsoft.com

First test was on a machine that sits on our network that can talk to a DNS
server.
I started up Ethereal and from command line I ran the following
c:> telnet windowsupdate.microsoft.com 80
followed by
c:> telnet 207.46.18.94 80
Ethereal showed that the resolution was performed by the DNS server and not
the Hosts table - this is not an expected behaviour as I am sure that I read
that the hosts table is used first to resolve, then DNS , WINS etc.

Ethereal info for first telent command:
- shows a DNS query to my DNS server for windowsupdate.microsoft.com and a
response back to my machine
- followed by an HTTP request to 207.46.225.221 and response Note: that the
IP address is not the same as the one I put in my Hosts table and
207.46.225.221 is nowhere to be found in my hosts file

Ethereal info for second telnet command:
- shows the standard TCP syn/ack over HTTP to the IP given in the command
(207.46.18.94). This is expected behaviour.

Second Test:
This time I choose another host name (207.46.232.189 genuine.microsoft.com)
that I have in my hosts table.
Start up Ethereal and
c:> telnet genuine.microsoft.com 80

Ethereal results (as expected):
- shows NO DNS Query to DNS server (because it is using the Hosts file)
- shows standard TCP syn/ack requests over HTTP to/from 207.46.232.189

Third Test:
This time I remove genuine.microsoft.com from Hosts file and repeat second
test
Start up Ethereal
c:> telnet genuine.microsoft.com 80

Ethereal Results (as expected):
- Shows DNS Query and response for genuine.microsoft.com
- shows standard TCP syn/ack requests over HTTP to/from 207.46.232.190

This proves to me the theory that certain host names are ignored within the
hosts file - probably done to prevent viruses from affecting Windows update.

Fourth Test:
This time I put in a bogus DNS server in my settings to see if I could force
the resolution to my Hosts file.
Start up Ethereal
c:> telnet windowsupdate.microsoft.com 80

Ethereal Results
- multiple DNS queries were sent to the bogus DNS server but no response, if
I changed the DNS server to 127.0.0.1 the result was no DNS queries at all.
- the Hosts file was ignored for the bogus DNS and if I used 127.0.0.1 as
DNS server. I could not resolve the host name windowsupdate.microsoft.com


Do you guys thnk I should give up on being able to use windows update or
automatic updates without establishing a connection with a valid DNS server?
Brent

"Robert Aldwinckle" wrote:

> "dak" <postmaster@[127.0.0.1]> wrote in message news:
> ....
> >>Any better ideas for proving or disproving it?
> >>
> > Sorry, no, but he might consider adding entries for V5 and V6 update
> > addresses, just in case. The only other thing I can think of is to
> > check the registry to ensure there is no redirection to another HOSTS
> > file, though that doesn't seem to be the case here.
>
> Agreed. That's why I suggested a packet trace
> but we still don't have an explanation for his counter-examples
> using ping which I would also like to see traced.
>
> I suppose I should trace ping myself sometime.
> If it has the equivalent of an HTTP HOST: header
> when a symbolic address has been given and that was
> resulting in a redirect we would have an explanation
> for that symptom too.
>
>
> Robert
> ---
>
>
>

"Brent" <> wrote in message
news:E73218F6-6599-4A91-8067-
....
> Do you guys thnk I should give up on being able to use windows update or
> automatic updates without establishing a connection with a valid DNS server?


Try avoiding the alias? Did the canonical name ever get used in a request?

<example>
Non-authoritative answer:
Name: windowsupdate.microsoft.nsatc.net
Address: 207.46.18.94
Aliases: windowsupdate.microsoft.com
</example>


Also since you are interested in using only HOSTS for name resolution
have you tried stopping dnscache service?


BTW notice that this is a canonical name (not an alias). Coincidence?

<example>
Non-authoritative answer:
Name: genuine.microsoft.com
Address: 207.46.232.190
</example>


> 207.46.225.221 is nowhere to be found in my hosts file


Out of curiosity where was it in the Ethereal trace? E.g. expand the DNS response.


Good luck

Robert
---