DNS or WINs issue I do not know

[ss]

I am haveing a strang issue on my Win2003 system.
two third party apps I have installed have displayed computer names with the
worng IP address. I used a nslookup on the DNS servers and they resolve the
connect names and IP address. WINs looks ok but I don't know. but I
rebuilted them just incase.
Recntly we needed to populate the host files on the servers since they are
not resolving.
How can i resolve this so I can remove the host files.

 

[Kevin D. Goodknecht Sr. [MVP]]

I am haveing a strang issue on my Win2003 system.
two third party apps I have installed have displayed computer names
with the worng IP address. I used a nslookup on the DNS servers and
they resolve the connect names and IP address. WINs looks ok but I
don't know. but I rebuilted them just incase.
Recntly we needed to populate the host files on the servers since
they are not resolving.
How can i resolve this so I can remove the host files.

What are the apps and what is the IP addresses?
Some applications have their own DNS lookup algorithm and may not be using
the DNS client.
(for instance nslookup is one of these, it has its own cache and bypasses
the client DNS cache and the hosts file, but it still uses the DNS suffix
search list from the DNS client)

It would be interesting to know if the apps are using the DNS Client service
cache, or checking the hosts file directly and if it uses the DNS suffix
search list and search order. There are sometimes big problems with the DNS
suffix search list because of this.


An example of a problem with a DNS suffix search list problem is if your
domain has a third level or lower name. (domain.domain.com) The DNS client
will search down to the second level name domain.com, on all queries not
appended with a trailing dot "domain.com.", some second level domains have a
wildcard record in it causing any name in the second level domain to resolve
to this record. What happens is the DNS client will send names starting at
the lower level, "domain.domain.com", if the name is not found it searches
"domain.com" and that's where the problem hits, because if the name is not
in the local domain.domain.com zone it will hit the wildcard record and
resolve.

 

[ss]

the apps are Trackit HelpDesk and Apple remote access. However Backup Exec
also stoped reconising the servers and until i entered the host file
browsing stopped from a remote office.

 

[Ace Fekay [MVP]]

In

the apps are Trackit HelpDesk and Apple remote access. However Backup
Exec also stoped reconising the servers and until i entered the host
file browsing stopped from a remote office.

I'm not sure about Trackit or Apple remote access, but Veritas definitely
uses NetBIOS (WINS). I would assume Trackit does since if I remember
correctly it has a browse feature, but not sure about Apple remote unless
it's OSx and you've configured it with your WINS server. Check your WINS
server database for the name and what IP shows up.

--
Ace

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

If you are having difficulty in reading or finding responses to your post,
instead of the website you are using, if I may suggest to use OEx (Outlook
Express or any other newsreader of your choosing), and configure a newsgroup
account, pointing to news.microsoft.com. This is a direct link into the
Microsoft Public Newsgroups, and it is FREE and DOES NOT require a Usenet
account with your ISP. With OEx, you can easily find your post, track
threads, cross-post, and sort by date, poster's name, watched threads or
subject.

Not sure how? It's easy:
How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Windows Server Directory Services
Microsoft Certified Trainer
Assimilation Imminent. Resistance is Futile.
Infinite Diversities in Infinite Combinations.
=================================

 

[Deji Akomolafe]

for instance nslookup is one of these, it has its own cache and bypasses
Kevin, do you consider the behavior of bypassing client's host file a flaw?
I'm wondering because it appears to be understandably "by design" if you
consider the fact that nslookup is not asking the client for the info. It is
asking a specific server to which it's focused. Looking at the client's host
file will skew the reliability of nslookup's result. No?

Deji

 

[Deji Akomolafe]

Is it possible that there are duplicate entries for one host (or IP address)
inside your WINS or DNS? I am wondering if scavenging is f-ing up your DNS
records and your apps are getting referred to incorrect hosts as a result.

Since host files seem to help you, I'd think that the apps are getting wrong
info from your WINS/DNS servers. This is where I will invest my
investigative capital.

Deji

 

[Kevin D. Goodknecht Sr. [MVP]]

Kevin, do you consider the behavior of bypassing client's host file a
flaw? I'm wondering because it appears to be understandably "by
design" if you consider the fact that nslookup is not asking the
client for the info. It is asking a specific server to which it's
focused. Looking at the client's host file will skew the reliability
of nslookup's result. No?

Deji,
I wouldn't say it is a flaw if it bypasses the local DNS cache, it is a
designed in behavior. Just like it does when nslookup does the reverse
lookup on the server IP it is using.
Some people call it a flaw because you didn't ask nslookup to do a PTR
lookup, it just does it. Which then freaks out some users into thinking
their DNS server is broken, because it can't find the "server name" for the
address.

I do think that if you disable using parent suffixes of the primary DNS
suffix on the client, nslookup should follow that. As it is the only way you
can get nslookup to not search parent suffixes of the primary DNS suffix is
to configure a custom DNS suffix search list. Nslookup will follow that.

 

[Herb Martin]

Deji,
I wouldn't say it is a flaw if it bypasses the local DNS cache, it is a
designed in behavior. Just like it does when nslookup does the reverse
lookup on the server IP it is using.

Kevin is correct, and you can use Ping or "Net View" to invoke
other name resolution methods.

Some people call it a flaw because you didn't ask nslookup to do a PTR
lookup, it just does it. Which then freaks out some users into thinking
their DNS server is broken, because it can't find the "server name" for
the
address.

That is a flaw (perhaps not a design flaw but certainly one of presentation
AT LEAST.)

I do think that if you disable using parent suffixes of the primary DNS
suffix on the client, nslookup should follow that. As it is the only way
you
can get nslookup to not search parent suffixes of the primary DNS suffix
is
to configure a custom DNS suffix search list. Nslookup will follow that.

Actually I think you can do it by make the name a (TRULY) FQDN:

Terminate the name with a "."

Contrary to popular misconceptions, a DNS name is NOT an "FQDN"
until it is to terminated by a "." (fully qualifies it.)

 

[Deji Akomolafe]

When you invoke nslookup, you are asking it to go ask a server for info. You
are not using it to tell you what the client knows. So, what do you consider
a "presentation flaw" in this instance.

You are correct on the ping and net view part, but we are talking nslookup
here.

You are also correct on the FQDN part, and that's the way it's worded in the
relevant RFCs.

Deji

Deji,
I wouldn't say it is a flaw if it bypasses the local DNS cache, it is a
designed in behavior. Just like it does when nslookup does the reverse
lookup on the server IP it is using.

Kevin is correct, and you can use Ping or "Net View" to invoke
other name resolution methods.

Some people call it a flaw because you didn't ask nslookup to do a PTR
lookup, it just does it. Which then freaks out some users into thinking
their DNS server is broken, because it can't find the "server name" for
the
address.

That is a flaw (perhaps not a design flaw but certainly one of
presentation
AT LEAST.)

I do think that if you disable using parent suffixes of the primary DNS
suffix on the client, nslookup should follow that. As it is the only way
you
can get nslookup to not search parent suffixes of the primary DNS suffix
is
to configure a custom DNS suffix search list. Nslookup will follow that.

Actually I think you can do it by make the name a (TRULY) FQDN:

Terminate the name with a "."

Contrary to popular misconceptions, a DNS name is NOT an "FQDN"
until it is to terminated by a "." (fully qualifies it.)




--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

 

[Kevin D. Goodknecht Sr. [MVP]]

That is a flaw (perhaps not a design flaw but certainly one of
presentation AT LEAST.)


Actually I think you can do it by make the name a (TRULY) FQDN:

Terminate the name with a "."

Sure you can stop nslookup from appending any suffixes by appending the name
with the root, but then if you do that it also won't append the primary or
connection DNS suffix either.

The problem is when the primary DNS suffix is a third level domain name. You
can assume that most of the local hosts are in the third level domain name,
e.g. sub.example.com., so you really don't need to search its parent suffix
if the zone isn't local to your DNS server. The only way I've found to
remove example.com. from nslookup's DNS suffix search is to configure a
custom DNS suffix search list of just sub.example.com.
Without doing this nslookup searches example.com. which gets resolved from
the internet. It works as long as example.com. exists on the internet AND it
does not have a wildcard record in its zone.
The wildcard record causes every query that doesn't have a record in the
sub.example.com. to hit the wildcard record in example.com. and resolve,
even if the name has a valid record in another domain. I've had three
threads this week alone with this behavior, and it just came to my attention
the nslookup ignores the setting to not append the parent suffixes of the
primary DNS suffix.
In my opinion, that is a real bug in nslookup. You would think that if
nslookup is going to use the suffix search list in TCP/IP properties, and
you remove the suffix by clearing the box, and the ipconfig /all removes the
suffix from the search list, why can't nslookup remove it?
Clearing the check box works for the DNS Client service, but if you are
trying to help someone with the problem that barely knows how to turn the PC
on, it makes if difficult to convince them that the problem is fixed if
nslookup still hits the wildcard record.

 

[sal]

OK, Thanks this is a little above me. But back to the problem at hand.
- I preformed a nslookup of several workstations using all the local DNS
servers (there are 2), and they reply correctly.
- I reviewed the WINs tables they seem correct, but I scavenge the WINs
servers it did not help so I rebuilt them (there are 2 and they are the DNS
servers as well).

if I ping -a the ip address the incorrect NetBIOS name appears. The same
thing happens if I tracert the address. the address resolves properly but at
the end of the trace the

tmarks address is 10.10.193.113 she is in a different vlan than mine, but
this also happens in the same vlan see below

C:\Documents and Settings\tech>ping 10.10.192.75

Pinging 10.10.192.75 with 32 bytes of data:

Reply from 10.10.192.75: bytes=32 time<1ms TTL=127
Reply from 10.10.192.75: bytes=32 time<1ms TTL=127
Reply from 10.10.192.75: bytes=32 time<1ms TTL=127
Reply from 10.10.192.75: bytes=32 time<1ms TTL=127

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

C:\Documents and Settings\tech>ping -a 10.10.192.75

Pinging tmarks.agency.com [10.10.192.75] with 32 bytes of data:

Reply from 10.10.192.75: bytes=32 time<1ms TTL=127
Reply from 10.10.192.75: bytes=32 time<1ms TTL=127
Reply from 10.10.192.75: bytes=32 time<1ms TTL=127
Reply from 10.10.192.75: bytes=32 time<1ms TTL=127

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

C:\Documents and Settings\tech>tracert 10.10.192.75

Tracing route to sscott.agency.com [10.10.192.75]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 10.10.191.1
2 <1 ms <1 ms <1 ms tmarks.agency.com [10.10.192.75]

Trace complete.

C:\Documents and Settings\tech>
"Ace Fekay [MVP]"

 

[Ace Fekay [MVP]]

In Kevin D. Goodknecht Sr. [MVP] <[email protected]> stated, which I
commented on below:

In my opinion, that is a real bug in nslookup. You would think that if
nslookup is going to use the suffix search list in TCP/IP properties,
and you remove the suffix by clearing the box, and the ipconfig /all
removes the suffix from the search list, why can't nslookup remove it?
Clearing the check box works for the DNS Client service, but if you
are trying to help someone with the problem that barely knows how to
turn the PC on, it makes if difficult to convince them that the
problem is fixed if nslookup still hits the wildcard record.

Has anyone tried this with Dig?

Ace