A problem with "hosts" file: hostnames with dots are not being resolved

  • Thread starter Thread starter Yarik
  • Start date Start date
Y

Yarik

Hi,

When I include the following two entries into my "hosts" file

192.168.1.22 zzyzx
192.168.1.22 zzyzx.com

the first hostname (the one without dots) is being resolved just fine,
but the second hostname (the one that does have a dot) isn't. What
could be a cause of such strange behavior and how this problem could be
fixed?

When this computer was set up for the first time, this problem did not
occur. I believe it started to occur at some point, but unfortunately,
I do not remember exactly when. I just remember that several months ago
one of the hostnames defined in the "hosts" file suddenly became
unresolvable, but at that point it was not important enough to
investigate; now I desperately need to include some hostnames with
dots...

Please, help! I cannot believe I am the first one stepping on this
problem. :-)

Thank you,
Yarik.

P.S. The computer runs Windows 2000 Server SP4.
 
In
Yarik said:
Hi,

When I include the following two entries into my "hosts" file

192.168.1.22 zzyzx
192.168.1.22 zzyzx.com

the first hostname (the one without dots) is being resolved just fine,
but the second hostname (the one that does have a dot) isn't. What
could be a cause of such strange behavior and how this problem could
be fixed?

When this computer was set up for the first time, this problem did not
occur. I believe it started to occur at some point, but unfortunately,
I do not remember exactly when. I just remember that several months
ago one of the hostnames defined in the "hosts" file suddenly became
unresolvable, but at that point it was not important enough to
investigate; now I desperately need to include some hostnames with
dots...

Please, help! I cannot believe I am the first one stepping on this
problem. :-)

Thank you,
Yarik.

P.S. The computer runs Windows 2000 Server SP4.
Click to expand...

How many entries are in the hosts file?

Did you eliminate the possibitlity of a virus (the Qhosts virus), or spyware
that may have hijacked the file?

When you do an ipconfig /flushdns, then an ipconfig displaydns, does the
entries you put in show up with the dots? Right after that, try to ping both
entries, and post your results.

--
Ace
Innovative IT Concepts, Inc (IITCI)
Willow Grove, PA

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Directory Services
Microsoft Certified Trainer

Having difficulty reading or finding responses to your post?
Instead of the website you're using, I suggest to use OEx (Outlook Express
or any other newsreader), and configure a news account, pointing to
news.microsoft.com. This is a direct link to the Microsoft Public
Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows you
to easily find, track threads, cross-post, sort by date, poster's name,
watched threads or subject.
It's easy:

How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Infinite Diversities in Infinite Combinations
Assimilation Imminent. Resistance is Futile
"Very funny Scotty. Now, beam down my clothes."

The only constant in life is change...
 
Did you eliminate the possibitlity of a virus (the Qhosts virus), or spyware
that may have hijacked thefile?
Click to expand...

No. I would appreciate any pointer on how to do that.
When you do an ipconfig /flushdns, then an ipconfig displaydns, does the
entries you put in show up with thedots?
Yes.

Right after that, try to ping both
entries, and post your results.
Click to expand...

Below is what I get (just in case, I restarted DNS Client service right
before the experiment).

NOTE: In our intranet, failure to resolve a host/domain name has
some... peculiarity. It never happens. :-) I don't know why, but our IT
folks use OpenDNS service: whenever their DNS server can't resolve a
host/domain name it returns IP of their OpenDNS's website,
208.67.219.41. I guess, the goal of this trick (IMHO, a dirty one) is
to make a misdirected browser show a page advertizing OpenDNS and full
of Google ads. In any case, on the screenshots below, ping's failure to
resolve a domain name actually looks like successful discovery of
208.67.219.41 address.


================================= Flush DNS Cache
P:\Projects>ipconfig /flushdns

Windows 2000 IP Configuration

Successfully flushed the DNS Resolver Cache.

================================= Display DNS Cache
P:\Projects>ipconfig /displaydns

Windows 2000 IP Configuration

localhost.
------------------------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . :
127.0.0.1


zzyzx.
------------------------------------------------------
Record Name . . . . . : zzyzx
Record Type . . . . . : 1
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . :
192.168.1.22


1.0.0.127.in-addr.arpa.
------------------------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa
Record Type . . . . . : 12
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . :
localhost


zzyzx.com.
------------------------------------------------------
Record Name . . . . . : zzyzx.com
Record Type . . . . . : 1
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . :
192.168.1.22


22.1.168.192.in-addr.arpa.
------------------------------------------------------
Record Name . . . . . : 22.1.168.192.in-addr.arpa
Record Type . . . . . : 12
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . :
zzyzx.com

Record Name . . . . . : 22.1.168.192.in-addr.arpa
Record Type . . . . . : 12
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . :
zzyzx

================== Ping hostname WITHOUT a dot - succeeds
P:\Projects>ping zzyzx

Pinging zzyzx [192.168.1.22] with 32 bytes of data:

Reply from 192.168.1.22: bytes=32 time<10ms TTL=128
Reply from 192.168.1.22: bytes=32 time<10ms TTL=128
Reply from 192.168.1.22: bytes=32 time<10ms TTL=128
Reply from 192.168.1.22: bytes=32 time<10ms TTL=128

Ping statistics for 192.168.1.22:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

================== Ping hostname WITHOUT a dot - fails
P:\Projects>ping zzyzx.com

Pinging zzyzx.com [208.67.219.41] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 208.67.219.41:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
 
In
Yarik said:
No. I would appreciate any pointer on how to do that.
Click to expand...

Not to sound facetious, but a qualified antivirus program can do this. You
can physically check the registry under H+HKLM\CCS\services\TCP\database
path. That should point to system32\drivers\etc\
When you do an ipconfig /flushdns, then an ipconfig displaydns, does
the entries you put in show up with thedots?
Yes.

Right after that, try to ping both
entries, and post your results.
Click to expand...

Below is what I get (just in case, I restarted DNS Client service
right before the experiment).

NOTE: In our intranet, failure to resolve a host/domain name has
some... peculiarity. It never happens. :-) I don't know why, but our
IT folks use OpenDNS service: whenever their DNS server can't resolve
a host/domain name it returns IP of their OpenDNS's website,
208.67.219.41. I guess, the goal of this trick (IMHO, a dirty one) is
to make a misdirected browser show a page advertizing OpenDNS and full
of Google ads. In any case, on the screenshots below, ping's failure
to resolve a domain name actually looks like successful discovery of
208.67.219.41 address.


================================= Flush DNS Cache
P:\Projects>ipconfig /flushdns

Windows 2000 IP Configuration

Successfully flushed the DNS Resolver Cache.

================================= Display DNS Cache
P:\Projects>ipconfig /displaydns

Windows 2000 IP Configuration

localhost.
------------------------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . :
127.0.0.1


zzyzx.
------------------------------------------------------
Record Name . . . . . : zzyzx
Record Type . . . . . : 1
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . :
192.168.1.22


1.0.0.127.in-addr.arpa.
------------------------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa
Record Type . . . . . : 12
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . :
localhost


zzyzx.com.
------------------------------------------------------
Record Name . . . . . : zzyzx.com
Record Type . . . . . : 1
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . :
192.168.1.22


22.1.168.192.in-addr.arpa.
------------------------------------------------------
Record Name . . . . . : 22.1.168.192.in-addr.arpa
Record Type . . . . . : 12
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . :
zzyzx.com

Record Name . . . . . : 22.1.168.192.in-addr.arpa
Record Type . . . . . : 12
Time To Live . . . . : 31525413
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . :
zzyzx

================== Ping hostname WITHOUT a dot - succeeds
P:\Projects>ping zzyzx

Pinging zzyzx [192.168.1.22] with 32 bytes of data:

Reply from 192.168.1.22: bytes=32 time<10ms TTL=128
Reply from 192.168.1.22: bytes=32 time<10ms TTL=128
Reply from 192.168.1.22: bytes=32 time<10ms TTL=128
Reply from 192.168.1.22: bytes=32 time<10ms TTL=128

Ping statistics for 192.168.1.22:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

================== Ping hostname WITHOUT a dot - fails
P:\Projects>ping zzyzx.com

Pinging zzyzx.com [208.67.219.41] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 208.67.219.41:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Click to expand...


That is sad that OpenDNS does that. Kind of crazy if you ask me.

But anyway, I know youmeant ping hostname with a dot fails (you said
without).

Is the DHCP Client service running? That is actually a required service for
resolution whether the machine is configured for DHCP or is statically
configured (like a server).

Alsom, you have two reverse entries for 192.168.1.22. There should only be
ONE. Choose one of them.

Curious, when you ping:
ping -a 192.168.1.22
what happens?

Ace
 
Not to sound facetious, but a qualified antivirus program can do this. You
can physically check the registry under H+HKLM\CCS\services\TCP\database
path. That should point to system32\drivers\etc\
Click to expand...

Registry appears to be OK. I don't know whether The Cleaner qualifies,
but it did not find anything either...
Is the DHCP Client service running?
Yes.

Alsom, you have two reverse entries for 192.168.1.22. There should only be
ONE. Choose one of them.
Click to expand...

I am not sure I know how to do that.

But doesn't that happen simply because I have two names in the HOSTS
file referring to the same IP address (which, I believe, is perfectly
legal)?
Curious, when you ping:
ping -a 192.168.1.22
what happens?
Click to expand...

I get this:

P:\Projects>ping -a 192.168.1.22

Pinging zzyzx [192.168.1.22] with 32 bytes of data:
...

Actually, I've just noticed that if I swap the entries for "zzyzx" and
"zzyzx.com", I get

P:\Projects>ping -a 192.168.1.22

Pinging zzyzx.com [192.168.1.22] with 32 bytes of data:

So it looks like the domain name returned by "ping -a" is taken from
the first line in HOSTS that points to the given IP address. (This
swapping does not make the problem go away, though... :-)

BTW, when you mentioned DHCP, I've realized that I should not be using
my computer's current IP address (192.168.1.22) in the HOSTS file
because this address theoretically may change by DHCP server on next
reboot. So I replaced it by 121.0.0.1.

Anyway, the problem is still there and, slowly by surely, I become
desperate... :-(( Any more ideas what could be wrong with my computer?

Thank you,
Yarik.

P.S. I've just found that, while we were discussing this problem, the
"zzyzx.com" domain name has been taken! I mean it has been registered
by some real company. Now pinging of that domain name goes to some
company's IP address (still ignoring the record in HOSTS).
 
In
Yarik said:
I am not sure I know how to do that.

But doesn't that happen simply because I have two names in the HOSTS
file referring to the same IP address (which, I believe, is perfectly
legal)?
Click to expand...

Legal, but confusing. I am saying choose the correct one you want to use for
..22. Delete the other one out of the hosts file.
Curious, when you ping:
ping -a 192.168.1.22
what happens?
Click to expand...

I get this:

P:\Projects>ping -a 192.168.1.22

Pinging zzyzx [192.168.1.22] with 32 bytes of data:
...

Actually, I've just noticed that if I swap the entries for "zzyzx" and
"zzyzx.com", I get

P:\Projects>ping -a 192.168.1.22

Pinging zzyzx.com [192.168.1.22] with 32 bytes of data:

So it looks like the domain name returned by "ping -a" is taken from
the first line in HOSTS that points to the given IP address. (This
swapping does not make the problem go away, though... :-)
Click to expand...

Yes, anothe rreason to delete the one you don't want.

Also, when you pinged zzyzx.com, notice it resolved to: [208.67.219.41]?
That is because it is an FQDN and hosts files don't work with FQDNs, so
therefore it revereted to DNS resolution, and resolved the outside IP
address.

Curious, do you have an ISP's (or any other outside DNS) address in IP
properties? I can see this causing this too. So probably what you are seeing
is default behavior.
BTW, when you mentioned DHCP, I've realized that I should not be using
my computer's current IP address (192.168.1.22) in the HOSTS file
because this address theoretically may change by DHCP server on next
reboot. So I replaced it by 121.0.0.1.
Click to expand...


You mean 127.0.0.1?

Anyway, the problem is still there and, slowly by surely, I become
desperate... :-(( Any more ideas what could be wrong with my computer?

Thank you,
Yarik.

P.S. I've just found that, while we were discussing this problem, the
"zzyzx.com" domain name has been taken! I mean it has been registered
by some real company. Now pinging of that domain name goes to some
company's IP address (still ignoring the record in HOSTS).
Click to expand...

Yep, see my reasons above.

Ace
 
Yarik said:
On Jan 30, 9:08 pm, "Ace Fekay [MVP]" <[email protected]>
wrote:
Click to expand...


It is perfectly legal to have many names for an address in the
host file but usually is to have them all on the SAME line:

192.168.2.1 Name1 Name2 Name3.whatever

Dots are also legal but have no "hierarchical meaning, they are merely
characters.

Did you put a DOT at the end of the name (try resolving with and without
that) -- the name with a terminating dot would be different than the one
with a dot -- extra CHARACTER.

DNS uses dots for seperators and a terminator...hosts does not.

Also, why are you fooling with a hosts file anyway?
 
First of all, I must inform you that the problem is gone.

To me - almost as mysteriously as it occurred.

It was gone after removing MS Proxy Client from the suffering
computer.

The official explanation from our IT guys: The computer is suspected
to carry some virus or trojan (something that tries to use port 139 to
communicate with suspicious Internet hosts), and it was some
interaction between this virus/trojan and MS Proxy Client that caused
malfunctioning of HOSTS-based name resolution mechanism.

Does not sound very plausible, if you ask me... However, removal of MS
Proxy Client (and whatever else they did without telling me) actually
solved multiple problems. In particular, the computer suddenly became
able to use Microsoft Update service, which it couldn'd use for about
two years (it would be no wonder for it to catch some pests during
that time!).

Legal, but confusing. I am saying choose the correct one you want to use for
.22. Delete the other one out of the hosts file.
Click to expand...

The point is, I have to have multiple names resolving to the same IP
address. This is used to redirect a couple of applications from
production servers (whose names are hardcoded) to "development
sandbox" servers installed on the computer.

Frankly, I do not see anything confusing it this either, but it may be
just me...

Also, when you pinged zzyzx.com, notice it resolved to: [208.67.219.41]?
That is because it is an FQDN and hosts files don't work with FQDNs, so
therefore it revereted to DNS resolution, and resolved the outside IP
address.
Click to expand...

Hmm, I don't think so. FQDNs in HOSTS worked just fine before the
problem occurred and are working just fine now...
Curious, do you have an ISP's (or any other outside DNS) address in IP
properties? I can see this causing this too. So probably what you are seeing
is default behavior.
Click to expand...

As I mentioned before, the real cause of the problem remains unknown.
It could be a virus indeed. Yet, I believe it could be some mis-
configuration of MS Proxy and/or MS Proxy Client. Unfortunately (or
fortunately? ;-) I do not have full visibility to what our IT folks
are doing, but I have reasons to believe that the problem was a result
of their never-ending Crusade for Tighter Security...
You mean 127.0.0.1?
Click to expand...

Sure. Sorry for typo...

Thank you for all your help!!!

Sincerely,
Yarik.
 
Did you put a DOT at the end of the name (try resolving with and without
that) -- the name with a terminating dot would be different than the one
with a dot -- extra CHARACTER.

DNS uses dots for seperators and a terminator...hosts does not.
Click to expand...

As you can see from the console screenshots that I posted, in order to
demonstrate the problem I used PING, which I believe does not want to
see dots at the ends of domain/host names.

Isn't dot-at-the-end a thing that has some meaning for NSLOOKUP
utility only? As far as I know, NSLOOKUP ignores HOSTS file
entirely...
Also, why are you fooling with a hosts file anyway?
Click to expand...

See my previous post (last response to Ace). Essentially, I use HOSTS
to redirect applications from production to "sandbox" servers.

Regards,
Yarik.
 
Yarik said:
First of all, I must inform you that the problem is gone.

To me - almost as mysteriously as it occurred.

It was gone after removing MS Proxy Client from the suffering
computer.

The official explanation from our IT guys: The computer is suspected
to carry some virus or trojan (something that tries to use port 139 to
communicate with suspicious Internet hosts), and it was some
interaction between this virus/trojan and MS Proxy Client that caused
malfunctioning of HOSTS-based name resolution mechanism.

Does not sound very plausible, if you ask me... However, removal of MS
Proxy Client (and whatever else they did without telling me) actually
solved multiple problems. In particular, the computer suddenly became
able to use Microsoft Update service, which it couldn'd use for about
two years (it would be no wonder for it to catch some pests during
that time!).
Click to expand...

Nor to me. It sounds like total bull. Either a cover story or from
ignorance.
Legal, but confusing. I am saying choose the correct one you want to use
for
.22. Delete the other one out of the hosts file.
Click to expand...

The point is, I have to have multiple names resolving to the same IP
address. This is used to redirect a couple of applications from
production servers (whose names are hardcoded) to "development
sandbox" servers installed on the computer.

Frankly, I do not see anything confusing it this either, but it may be
just me...

Also, when you pinged zzyzx.com, notice it resolved to: [208.67.219.41]?
That is because it is an FQDN and hosts files don't work with FQDNs, so
therefore it revereted to DNS resolution, and resolved the outside IP
address.
Click to expand...

Hmm, I don't think so. FQDNs in HOSTS worked just fine before the
problem occurred and are working just fine now...
Curious, do you have an ISP's (or any other outside DNS) address in IP
properties? I can see this causing this too. So probably what you are
seeing
is default behavior.
Click to expand...

As I mentioned before, the real cause of the problem remains unknown.
It could be a virus indeed. Yet, I believe it could be some mis-
configuration of MS Proxy and/or MS Proxy Client. Unfortunately (or
fortunately? ;-) I do not have full visibility to what our IT folks
are doing, but I have reasons to believe that the problem was a result
of their never-ending Crusade for Tighter Security...
You mean 127.0.0.1?
Click to expand...

Sure. Sorry for typo...

Thank you for all your help!!!

Sincerely,
Yarik.
Click to expand...
 
Yarik said:
As you can see from the console screenshots that I posted, in order to
demonstrate the problem I used PING, which I believe does not want to
see dots at the ends of domain/host names.
Click to expand...

No, ping has no "opinion" about the dots. If you put them there then
ping (the built-in resolver actually) will NOT append additional suffixes
but use the name exactly as supplied. If you don't the resolver will try
adding suffixes if the name is not matched.

Isn't dot-at-the-end a thing that has some meaning for NSLOOKUP
utility only? As far as I know, NSLOOKUP ignores HOSTS file
entirely...
Click to expand...

No, NSLookup has it's own resolver but it works similarly as far as the
dot -- it does NOT however use NetBIOS methods, the DNS cache,
nor the hosts file in trying resolutions.
See my previous post (last response to Ace). Essentially, I use HOSTS
to redirect applications from production to "sandbox" servers.
Click to expand...

Ok.

As to the "virus" story they told you I do agree. It was just a story most
likely.
 
In
Yarik said:
First of all, I must inform you that the problem is gone.

To me - almost as mysteriously as it occurred.

It was gone after removing MS Proxy Client from the suffering
computer.
Click to expand...

<snipped>

MS proxy client? Wow, never thought to ask about that! That could have
caused the WHOLE thing. Sometimes it is difficult to think of everything
when trying to tech support an issue and usually assume that a poster posted
everthing relevant. Or that in conjunction with a virus, but you originally
said the reg entry for the hosts file was untainted. Remember, the proxy or
firewall client (of ISA) alters the winsock DLL so it works with proxy and
some of the normal networking stuff we *assume* will work does NOT with the
client installed.

Ace
 
MS proxy client? Wow, never thought to ask about that! That could have
caused the WHOLE thing.
Click to expand...

MS Proxy Client *by itself*? It's very hard to believe because MSPC
was installed on that computer from the very beginning and did not
cause any problems. Specifically, *neither* of the problems that have
been "cured" by its removal were there until some moment in the past.

I still think that it was some fiddling with MS Proxy Server or
something like that...
 
In
Yarik said:
MS Proxy Client *by itself*? It's very hard to believe because MSPC
was installed on that computer from the very beginning and did not
cause any problems. Specifically, *neither* of the problems that have
been "cured" by its removal were there until some moment in the past.

I still think that it was some fiddling with MS Proxy Server or
something like that...
Click to expand...

Could have been. Difficult to say now. But MSPC introduces an additional
factor when it comes to networking, especially if the IT dept made changes.

Good luck!

Ace
 
Back
Top