Re: nslookup




"one3cap" <one3cap@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3F74FD3A-C448-491D-A213-7C4A3C66B5B7@xxxxxxxxxxxxxxxx
The thing that is puzzling me it seems as is DNS is working properly ( i
might be wrong! ) Because on these clients that are having the issue for
example they try to go to http://triton/emr they get a page cannot be

Internet Explorer (as opposed to Firefox but perhaps including MODERN
Netscape which uses an IE datapane) will see a "Short name with no dots"
and switch to (actual) NetBIOS resolution so you cannot be sure what you
are testing above.

When doing name resolution tests you should QUALIFY your names with
the actual domain suffix, and test that against unqualified names to ensure
you aren't seeing differences in NetBIOS vs. DNS or automatic appending of
the (wrong or right) DNS suffix.

displayed...... then i do my normal thing on the computer and try to:
ping triton and get "could not find host".... but if i do ping
triton.domain.local then i get "replies" and further \\triton =

Presumably your machine does NOT live in teh domain.local domain OR
if it does then the PRIMARY Domain Suffix is NOT properly set in the
System Control panel.

When testing use fully correct names and understand where those automatic
suffix come from if you do not, or how fail over to NetBIOS methods may
give different (either correct OR incorrect) results.

"could not find" but \\triton.domain.local "works"..... then i
go
to nslookup and this points to internal dns server and do a lookup for
triton it does find triton.domain.local with correct ip address this
is
in my eyes telling me that the client is getting proper dns name

NSLookup will NOT use the built-in name cache nor the hosts file NOR
will it fail over to NetBIOS methods.

The only thing "special" that NSLookup will do is to append your suffixes
on the end of the name if you don't FULLY* qualify it.

* A DNS Name is NOT a Fully Qualified DNS Name (FQDN) unless it
ENDS in a ".", i.e., a DOT.

Your main difficulty in understanding what it happening is that you are
only partially qualifying the names and not realizing the distinctions the
resolvers use.

You need to test FQDN's against those partial names and check perhaps
to see if NetBIOS methods are being used (either directly by IE or
indirectly
by the built-in resolver.)

NSLookup has it's own (private) resolver which is NOT the same as the
built-in resolver used by most programs (e.g., ping and IE when IE doesn't
use the NetBIOS resolver.)

resolution..... i was thinking a WINS issue because of the netbios name
it
was trying to resolve the name triton but the FQDN name of
triton.domain.local was working this is happening on mutiple
names
and then the helpdesk guys were doing a ipconfig /flushdns and
then
everything was working again which REALLY puzzled me because the nslookup
results were exactly the same after the flushdns command.

NSLookup's resolver IGNORES the DNS cache.

Ping uses the built-in resolver which uses the cache (so does IE for DNS
resolution.)

i might be wrong
looking at this from a WINS side but the \\triton not working but
the \\triton.domain.local working was telling me dns is fine but
then
the whole flushdns fixing it confused me.

Possible but unlikely from what I am reading.

What actually work incorrectly? What happens when you are ENTIRELY
specific with NSLookup and the various programs versus using the partial
name?

Remember what I said before too, that NSLookup can be told WHICH
DNS server to check so you can determine if SOME DNS server is working
but another is not.

Such situations cause their own set of INTERMITTANT and unpredictable
problems.

nsLookup trition.domain.local. IP.Every.DNSServerIn.IPConfig

You should check EVERY DNS server shown in "Ipconfig /all" individually.

You should use a FQDN (that dot on the end) to make SURE you are
really checking the name you think you are checking.

You should compare these results with using partial names and perhaps even
check with "NBTStat -r" to see what NetBIOS is resolving through WINS
server or by broadcast.

You can clear the NetBIOS cache with "NbtStat -R", view it, then test, and
then use "NBTStat -r" again to see if NetBIOS is being used.

NOTICE: NBTStat is one of the FEW Microsoft commands that is CASE
SENSITIVE. -r and -R have radically different meanings.

-r == SHOW the cache

-R == CLEAR the cache



"Herb Martin" wrote:


"one3cap" <one3cap@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F24B4A1E-D8D5-4244-A811-924EBBCD0E63@xxxxxxxxxxxxxxxx
this is a strange issue that just happened a few days ago it had been
working
fine for 1 year.

i have 20 remote sites and 1 main data center. 2 domain controllers in
my
main site
172.29.3.4 dns/dc/dhcp/wins
172.29.3.19 dns/dc
windows server 2003 enterprise
all my sites connect via fast wan links to main data center. ones of
those
servers are hosting dhcp successfully giving IP's to clients. All is
good
excpet for many clients in my northern division. we have many web based
apps
that use servername/appname.

the problem is not all but many are getting "page cannot be displayed"
now
when i remote into these computers i look at dns on clients and both
pri
and secondary dns is pointed to internal dns servers. i try to ping the
server by netbios name and get no reply but if i ping by FQDN i do get
a
reply. what i have to do to fix the issue is do a ipconfig /flushdns
and
all
is good but then i will get a call from the same client computer with
the
same issue.

That implies the problem is in the DNS Client Cache but generally this
starts
with a sick DNS Server or Servers. You clear it and then things
(apparently)
work briefly which tends to imply ONE instead of all DNS servers are
sick.

Check each of your DNS servers (configured on the clients) SPECIFICALLY.

Once you have such problems it is INSUFFICIENT to just do a default
NSLookup without checking each DNS server individually and specifically:

nslookup Server.Domain.Name IP.OfEach.DNS.Server

Clients cache NEGATIVE responses too, so if your DNS servers are
"working"
but returning NOTHING then this might be part of the problem.

when i run nslookup i get the proper internal dns server and set type=a
i
get an answer with ip for netbios name. i am puzzled as to what i
causing
this

You need to work through each DNS server systematically -- most likely

Make sure you didn't do "Mutual Forwarding" on your DNS Servers, e.g.,

Forwarding: DNS1 -> DNS2 and DNS2 -> DNS1





.



Relevant Pages

  • Re: AD clients can no longer connect to DC in 2003
    ... perhaps you should look at the clients. ... Verify that the clients are pointing to an existing, internal DNS server ... However it does not prove that the correct SRV records are present. ... >net start netlogin>>That should get logins going again. ...
    (microsoft.public.windows.server.active_directory)
  • RE: NT to AD upgrade question (advanced)
    ... The DNS Server that is in the DMZ, ... I cannot manually change the DNS setting on the clients. ... transfers the AD Integrated zone from the DC. ...
    (microsoft.public.windows.server.migration)
  • Re: setup/configure internal domain dns server?
    ... the ISP provided dns servers and not the main domain controller but I ... AD must have a DNS server setup for the AD domain. ... DNS server to itself for DNS, use the actual IP address not 127.0.0.1. ... Point all AD clients to the DNS server setup for the AD domain ONLY (Servers ...
    (microsoft.public.windows.server.dns)
  • Re: setup/configure internal domain dns server?
    ... the ISP provided dns servers and not the main domain controller but I ... AD must have a DNS server setup for the AD domain. ... DNS server to itself for DNS, use the actual IP address not 127.0.0.1. ... Point all AD clients to the DNS server setup for the AD domain ONLY (Servers ...
    (microsoft.public.windows.server.dns)
  • Re: DNS on AD-server refuse one single client
    ... > clients are member of the domain, ... Have you tried explicit resolution from the command line ... (I assume that the table has NSLookup and a command ... from both the problem client and the DNS server. ...
    (microsoft.public.win2000.dns)