PHWinfo banniere

Titres
PORTAIL ANNUAIRE ARTICLES COMPARATEUR HÉBERGEURS DEVIS FORUMS RÉDUCTEUR D'URL
Précédent   PHWinfo > Forums Hébergement > Forum Noms de domaine > ms.public.win.server.dns > FQDN
S'inscrire FAQ Membres Recherche Messages du jour Marquer les forums comme lus
FQDN

Réponse
 
LinkBack Outils de la discussion
Vieux 05/01/2007, 19h22   #1
Peter F
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut FQDN

Hi all,

I have a strange problem in that i am unable to ping my server using a FQDN.
i.e. i have 2 separate Domains (1 Physical Network, all home use) and i
cannot ping from 1 domain or the other using server001.flinty.com,
server002.contoso.com. However i am able to ping server001 and, server002. I
am also able to ping flinty.com and, contoso.com and, also both the IP
addresses.

I have checked on the DNS server but am unable to see what i need to
configure in order for the FQDN to be pinged correctly.

Any would be greatly appreciated.

Kind Regards.


--
Flinty
  Réponse avec citation
Vieux 05/01/2007, 20h25   #2
Herb Martin
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: FQDN

"Peter F" <PeterF@discussions.microsoft.com> wrote in message
news:4DCDD27F-5458-474A-AD34-5012753E0CC3@microsoft.com...
> Hi all,
>
> I have a strange problem in that i am unable to ping my server using a

FQDN.
> i.e. i have 2 separate Domains (1 Physical Network, all home use) and i
> cannot ping from 1 domain or the other using server001.flinty.com,
> server002.contoso.com. However i am able to ping server001 and, server002.

I
> am also able to ping flinty.com and, contoso.com and, also both the IP
> addresses.


> I have checked on the DNS server but am unable to see what i need to
> configure in order for the FQDN to be pinged correctly.


You almost certainly have a DNS problem -- as you likely have
realized despite being "unable to see" what you need to change.

We know that it is not a routing problem since you can ping the
location -- all pings (actually all IP traffic) actually travels by IP
address, not by name so the first step in all "pings" by name is to
resolve the name to an address and clearly yours works once
that is done.

There are many ways a name can be resolved: DNS using the
exact name, DNS after appending a client-side suffix onto it,
using a Hosts file on the client, WINS server for the machine name,
LMHosts file on the client, or broadcast for the machine name.

Notice that the NetBIOS methods (latter methods above) all
just guess or presume the "domain portion" will match and only
check the base name or simple (NetBIOS) computer name.

This is similar to what happens when suffixes are added automatically
by the client (and more or less similar when checking the Hosts file.)

Changes are the record is just not present in the DNS server your
are checking (and IF it is not the authoritative DNS server for that
name then it cannot find a different DNS server which does know the
answer.)

The problem could also be caused (or hidden even) by the client
having additional suffixes or checking 'parent' suffixes and thus
finding AN answer in some other zone than the one you intended.

You figure all this out by carefully comparing "IPConfig /all" (esp.
the computers domain name and additional DNS suffixes) against
the results you get when directly testing EVERY DNS server listed
for that client by using NSLookup and specifying both the full DNS
name against the partial name, as well as specifying a particular DNS
server to check:

nslookup computerName IP.Address.DNS.Server1
nslookup computer.domain.com IP.Address.DNS.Server1

nslookup computerName IP.Address.DNS.Server2
nslookup computer.domain.com IP.Address.DNS.Server2

And perhaps by checking NetBIOS resolution for names by using
"NBTStat -c".

Also check the LMHosts or Hosts files IF you have these (which
is relatively uncommon today but still seen). The direction to check
is here:

%systemroot%\system32\drivers\etc
hosts or lmhosts with no extensions

If you have more problem then just send the (unedited) TEXT output
of the NSLookup commands, IPConfig /all, and perhaps NTBSTAT -c,
or even the "dir" listing of the "%systemroot%\system32\drivers\etc" and
the contents of any Hosts or LMHosts files.

Usually we only need to see the IPConfig /all and the NSlookup to show
you the (probable) location of the problem.

IF the problem seems to be with the DNS server then GO LOOK in
the DNS console and see if you really have that zone there (or can find it
on another server through recursion or forwarding by YOUR DNS server),
and that the zone (wherever it is) contains that record you need.

Prove that SOME record from that zone can be resolved etc.

--
Herb Martin, MCSE MVP
www.LearnQuick.Com


  Réponse avec citation
Vieux 05/01/2007, 20h57   #3
Peter F
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: FQDN

Herb,

Thanks very much for taking the time to reply i will certainly attempt your
suggestions and, take it from there. I will report back if i have further
problems.

Kind Regards.
--
Flinty


"Herb Martin" wrote:

> "Peter F" <PeterF@discussions.microsoft.com> wrote in message
> news:4DCDD27F-5458-474A-AD34-5012753E0CC3@microsoft.com...
> > Hi all,
> >
> > I have a strange problem in that i am unable to ping my server using a

> FQDN.
> > i.e. i have 2 separate Domains (1 Physical Network, all home use) and i
> > cannot ping from 1 domain or the other using server001.flinty.com,
> > server002.contoso.com. However i am able to ping server001 and, server002.

> I
> > am also able to ping flinty.com and, contoso.com and, also both the IP
> > addresses.

>
> > I have checked on the DNS server but am unable to see what i need to
> > configure in order for the FQDN to be pinged correctly.

>
> You almost certainly have a DNS problem -- as you likely have
> realized despite being "unable to see" what you need to change.
>
> We know that it is not a routing problem since you can ping the
> location -- all pings (actually all IP traffic) actually travels by IP
> address, not by name so the first step in all "pings" by name is to
> resolve the name to an address and clearly yours works once
> that is done.
>
> There are many ways a name can be resolved: DNS using the
> exact name, DNS after appending a client-side suffix onto it,
> using a Hosts file on the client, WINS server for the machine name,
> LMHosts file on the client, or broadcast for the machine name.
>
> Notice that the NetBIOS methods (latter methods above) all
> just guess or presume the "domain portion" will match and only
> check the base name or simple (NetBIOS) computer name.
>
> This is similar to what happens when suffixes are added automatically
> by the client (and more or less similar when checking the Hosts file.)
>
> Changes are the record is just not present in the DNS server your
> are checking (and IF it is not the authoritative DNS server for that
> name then it cannot find a different DNS server which does know the
> answer.)
>
> The problem could also be caused (or hidden even) by the client
> having additional suffixes or checking 'parent' suffixes and thus
> finding AN answer in some other zone than the one you intended.
>
> You figure all this out by carefully comparing "IPConfig /all" (esp.
> the computers domain name and additional DNS suffixes) against
> the results you get when directly testing EVERY DNS server listed
> for that client by using NSLookup and specifying both the full DNS
> name against the partial name, as well as specifying a particular DNS
> server to check:
>
> nslookup computerName IP.Address.DNS.Server1
> nslookup computer.domain.com IP.Address.DNS.Server1
>
> nslookup computerName IP.Address.DNS.Server2
> nslookup computer.domain.com IP.Address.DNS.Server2
>
> And perhaps by checking NetBIOS resolution for names by using
> "NBTStat -c".
>
> Also check the LMHosts or Hosts files IF you have these (which
> is relatively uncommon today but still seen). The direction to check
> is here:
>
> %systemroot%\system32\drivers\etc
> hosts or lmhosts with no extensions
>
> If you have more problem then just send the (unedited) TEXT output
> of the NSLookup commands, IPConfig /all, and perhaps NTBSTAT -c,
> or even the "dir" listing of the "%systemroot%\system32\drivers\etc" and
> the contents of any Hosts or LMHosts files.
>
> Usually we only need to see the IPConfig /all and the NSlookup to show
> you the (probable) location of the problem.
>
> IF the problem seems to be with the DNS server then GO LOOK in
> the DNS console and see if you really have that zone there (or can find it
> on another server through recursion or forwarding by YOUR DNS server),
> and that the zone (wherever it is) contains that record you need.
>
> Prove that SOME record from that zone can be resolved etc.
>
> --
> Herb Martin, MCSE MVP
> www.LearnQuick.Com
>
>
>

  Réponse avec citation
Vieux 05/01/2007, 22h06   #4
Herb Martin
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: FQDN


"Peter F" <PeterF@discussions.microsoft.com> wrote in message
news:9114A549-CED5-484E-9F50-7C0D3441EB26@microsoft.com...
> Herb,
>
> Thanks very much for taking the time to reply i will certainly attempt

your
> suggestions and, take it from there. I will report back if i have further
> problems.


Be sure to do that if you have further problems. The key is to
avoid staying STUCK, as people here are happy to try to
if you will just ask....


  Réponse avec citation
Réponse


Outils de la discussion

Règles de messages
Vous ne pouvez pas créer de nouvelles discussions
Vous ne pouvez pas envoyer des réponses
Vous ne pouvez pas envoyer des pièces jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activées : oui
Les smileys sont activés : oui
La balise [IMG] est activée : oui
Le code HTML peut être employé : non
Trackbacks are oui
Pingbacks are oui
Refbacks are oui


Fuseau horaire GMT +1. Il est actuellement 11h49.


Édité par : vBulletin® version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0 RC5 Tous droits réservés.
Version française #16 par l'association vBulletin francophone
PHWinfo est un site Éducation Sans Frontières ©2000-2008
Ad Management by RedTyger
©Tous droits réservés par les parties respectives
Page generated in 0,12921 seconds with 12 queries