DHCP assinged DNS servers don't work

I've posted this issue in other newsgroups with little success. Hopefully
someone here can help me.

I have 75 WinXP machines on a Win2K3 domain using DHCP for address
assignment. I have found that for some machines, using the DHCP-provided DNS
servers fails to resolve all internal host names. If I use DHCP for the IP
address only and manually add the DNS servers, name resolution works every
time.

In more detail, if I use DHCP to assign the name servers, the ping command
will fail on certain internal hosts. However, nslookup works every time. If
I manually assign the name servers (using the same addresses provided by
DHCP) ping works and so does nslookup.

Any thoughts or ideas are greatly appreciated. This problem is preventing
me from taking a new system live because a number of machines can't resolve
the name.

Thanks,
Joe

Hello,
"Joe" <(E-Mail Removed)> wrote in message
news:249BBF41-75D1-4AD2-AEA9-(E-Mail Removed)...
> I've posted this issue in other newsgroups with little success. Hopefully
> someone here can help me.
>
> I have 75 WinXP machines on a Win2K3 domain using DHCP for address
> assignment. I have found that for some machines, using the DHCP-provided
> DNS
> servers fails to resolve all internal host names. If I use DHCP for the
> IP
> address only and manually add the DNS servers, name resolution works every
> time.
>
> In more detail, if I use DHCP to assign the name servers, the ping command
> will fail on certain internal hosts. However, nslookup works every time.
> If
> I manually assign the name servers (using the same addresses provided by
> DHCP) ping works and so does nslookup.
>
> Any thoughts or ideas are greatly appreciated. This problem is preventing
> me from taking a new system live because a number of machines can't
> resolve
> the name.
>
I have seen a similar behaviour only with the Windows Live One Care Firewall
on my laptop. That blocked DHCP and DNS traffic by default.
What is the output of ipconfig /all on the affected clients?
Are the client PCs "multihomed" (multiple network interfaces)?
Best greetings from Germany
Olaf

am going to "pile-on" this one becasue it sounds similar to a situation I am experiencing.
Randon (apparently) DHCP clients on my network are losing thier DNS entries. The users report what turn out to be connectivity problems with name based hosts (raw IP related ones obviously resolve just fine.)

IPCONFIG ends up revealing a single DNS server entry which is not on my network. I have had several different values, but they all fall in the 16x.X.X.X format. (Today's most recent one was 168.95.1.1)

The user PCs are able to reconnect temporarily by executing ipconfig /renew (or re-starting the system.)

C. Newell
Shiawassee County, MI

"Joe" <(E-Mail Removed)> wrote in message news:249BBF41-75D1-4AD2-AEA9-(E-Mail Removed)...
> I've posted this issue in other newsgroups with little success. Hopefully
> someone here can help me.
>
> I have 75 WinXP machines on a Win2K3 domain using DHCP for address
> assignment. I have found that for some machines, using the DHCP-provided DNS
> servers fails to resolve all internal host names. If I use DHCP for the IP
> address only and manually add the DNS servers, name resolution works every
> time.
>
> In more detail, if I use DHCP to assign the name servers, the ping command
> will fail on certain internal hosts. However, nslookup works every time. If
> I manually assign the name servers (using the same addresses provided by
> DHCP) ping works and so does nslookup.
>
> Any thoughts or ideas are greatly appreciated. This problem is preventing
> me from taking a new system live because a number of machines can't resolve
> the name.
>
> Thanks,
> Joe

Olaf,
An ipconfig /all printout is below. This is definately not a firewall
issue. Although the WinXP firewall is enabled and configured via Group
Policy, the problem only affects certain machines. (It does seem to affect
laptops more than desktops. Not sure why.) None of the clients are
multi-homed. The first two DNS servers are AD controllers running ONLY core
services (AD, DNS, DHCP, IAS, WINS.)

C:\>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : vmtest
Primary Dns Suffix . . . . . . . : internal.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : internal.com
internal.com

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : internal.com
Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network
Connecti
on
Physical Address. . . . . . . . . : 00-07-E9-D6-5A-D1
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.1.153
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.75
DHCP Server . . . . . . . . . . . : 192.168.1.38
DNS Servers . . . . . . . . . . . : 192.168.1.38
192.168.1.39
192.168.1.14
Primary WINS Server . . . . . . . : 192.168.1.38
Secondary WINS Server . . . . . . : 192.168.1.39
Lease Obtained. . . . . . . . . . : Tuesday, September 04, 2007
11:23:01
AM
Lease Expires . . . . . . . . . . : Wednesday, September 12, 2007
11:23:
01 AM

C:\>

"Olaf Engelke [MVP Windows Server]" wrote:

> Hello,
> "Joe" <(E-Mail Removed)> wrote in message
> news:249BBF41-75D1-4AD2-AEA9-(E-Mail Removed)...
> > I've posted this issue in other newsgroups with little success. Hopefully
> > someone here can help me.
> >
> > I have 75 WinXP machines on a Win2K3 domain using DHCP for address
> > assignment. I have found that for some machines, using the DHCP-provided
> > DNS
> > servers fails to resolve all internal host names. If I use DHCP for the
> > IP
> > address only and manually add the DNS servers, name resolution works every
> > time.
> >
> > In more detail, if I use DHCP to assign the name servers, the ping command
> > will fail on certain internal hosts. However, nslookup works every time.
> > If
> > I manually assign the name servers (using the same addresses provided by
> > DHCP) ping works and so does nslookup.
> >
> > Any thoughts or ideas are greatly appreciated. This problem is preventing
> > me from taking a new system live because a number of machines can't
> > resolve
> > the name.
> >
> I have seen a similar behaviour only with the Windows Live One Care Firewall
> on my laptop. That blocked DHCP and DNS traffic by default.
> What is the output of ipconfig /all on the affected clients?
> Are the client PCs "multihomed" (multiple network interfaces)?
> Best greetings from Germany
> Olaf
>
>

Hello Joe,
"Joe" <(E-Mail Removed)> schrieb im Newsbeitrag
news:4C20F207-EAA9-4108-9169-(E-Mail Removed)...
> Olaf,
> An ipconfig /all printout is below. This is definately not a firewall
> issue. Although the WinXP firewall is enabled and configured via Group
> Policy, the problem only affects certain machines. (It does seem to
> affect
> laptops more than desktops. Not sure why.) None of the clients are
> multi-homed. The first two DNS servers are AD controllers running ONLY
> core
> services (AD, DNS, DHCP, IAS, WINS.)
>
> C:\>ipconfig /all
>
> Ethernet adapter Local Area Connection:
>
> Connection-specific DNS Suffix . : internal.com
> Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network
> Connection
> Physical Address. . . . . . . . . : 00-07-E9-D6-5A-D1
> Dhcp Enabled. . . . . . . . . . . : Yes
> Autoconfiguration Enabled . . . . : Yes
> IP Address. . . . . . . . . . . . : 192.168.1.153
> Subnet Mask . . . . . . . . . . . : 255.255.255.0
> Default Gateway . . . . . . . . . : 192.168.1.75
> DHCP Server . . . . . . . . . . . : 192.168.1.38
> DNS Servers . . . . . . . . . . . : 192.168.1.38
> 192.168.1.39
> 192.168.1.14
> Primary WINS Server . . . . . . . : 192.168.1.38
> Secondary WINS Server . . . . . . : 192.168.1.39
looks all good in my eyes.

>> > In more detail, if I use DHCP to assign the name servers, the ping
>> > command
>> > will fail on certain internal hosts. However, nslookup works every
>> > time.
>> > If I manually assign the name servers (using the same addresses
>> > provided by
>> > DHCP) ping works and so does nslookup.
>> >
Well, some more questions (all shots into the blue):
How is your DNS server configured? In it's TCP/IP properties it should not
point to localhost ip address, but either to the real IP address or to the
second DNS server in AD as primary DNS server address. (I have seen issues
with name resolution before being caused by such configuration on server
side).
Does reverse lookup working properly (given you have created a reverse
lookup zone)? Can nslookup resolve the IP address back to the name?
These certain internal hosts - what are they? Could it be that you dont have
an AD integrated DNS and on of the DNS servers is unable to resolve the
questionable host names?
Use nslookup connect parameter to select the other DNS servers, if they work
as well.
With multiple DNS servers you don't have influence, which one the client
selects for name resolution finally. So may be it works, if you enter only
one DNS server, which knows these hosts, while with DHCP another DNS server
is queried which is unable to resolve the questionable names.
Check also that there are no manual additions of extensions to other/old/non
existent domains somewhere in the TCP/IP properties.
Best greetings from Germany
Olaf

Olaf,
Thanks again for responding. I know this particular problem is going to be
resolved in the details, so here are the answers to your questions.

How is your DNS server configured?
I have 2 AD-integrated DNS servers. They point to themselves and each other
via IP address. Replication between the two DNS servers works with no errors.

Does reverse lookup working properly?
Yes. I have rDNS zones created and they work.

These certain internal hosts - what are they?
The one host that is related to this problem is a web filter appliance.
Linux-based, it is not AD integrated. I have manually added the required A
Record in the DNS servers.

Use nslookup connect parameter to select the other DNS servers
Done. Nslookup works fine with either internal DNS server and correctly
resolves the host name in question.

With multiple DNS servers you don't have influence
The A Record exists on both internal DNS servers. Ping resolves the name
correctly (on certain machines) only if the DNS servers are specified
manually.

Check also that there are no manual additions of extensions to other/old/non
existent domains somewhere in the TCP/IP properties.
None. This domain has existed for years with no changes in domain name or
subnet. It has been upgraded from NT4.0 to W2K and now W2K3. We have been
at the current level for 3 years with no significant changes to structure or
schema.

Your thoughts are appreciated.
Thanks,
Joe


"Olaf Engelke [MVP Windows Server]" wrote:

> Hello Joe,
> "Joe" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:4C20F207-EAA9-4108-9169-(E-Mail Removed)...
> > Olaf,
> > An ipconfig /all printout is below. This is definately not a firewall
> > issue. Although the WinXP firewall is enabled and configured via Group
> > Policy, the problem only affects certain machines. (It does seem to
> > affect
> > laptops more than desktops. Not sure why.) None of the clients are
> > multi-homed. The first two DNS servers are AD controllers running ONLY
> > core
> > services (AD, DNS, DHCP, IAS, WINS.)
> >
> > C:\>ipconfig /all
> >
> > Ethernet adapter Local Area Connection:
> >
> > Connection-specific DNS Suffix . : internal.com
> > Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network
> > Connection
> > Physical Address. . . . . . . . . : 00-07-E9-D6-5A-D1
> > Dhcp Enabled. . . . . . . . . . . : Yes
> > Autoconfiguration Enabled . . . . : Yes
> > IP Address. . . . . . . . . . . . : 192.168.1.153
> > Subnet Mask . . . . . . . . . . . : 255.255.255.0
> > Default Gateway . . . . . . . . . : 192.168.1.75
> > DHCP Server . . . . . . . . . . . : 192.168.1.38
> > DNS Servers . . . . . . . . . . . : 192.168.1.38
> > 192.168.1.39
> > 192.168.1.14
> > Primary WINS Server . . . . . . . : 192.168.1.38
> > Secondary WINS Server . . . . . . : 192.168.1.39
> looks all good in my eyes.
>
> >> > In more detail, if I use DHCP to assign the name servers, the ping
> >> > command
> >> > will fail on certain internal hosts. However, nslookup works every
> >> > time.
> >> > If I manually assign the name servers (using the same addresses
> >> > provided by
> >> > DHCP) ping works and so does nslookup.
> >> >
> Well, some more questions (all shots into the blue):
> How is your DNS server configured? In it's TCP/IP properties it should not
> point to localhost ip address, but either to the real IP address or to the
> second DNS server in AD as primary DNS server address. (I have seen issues
> with name resolution before being caused by such configuration on server
> side).
> Does reverse lookup working properly (given you have created a reverse
> lookup zone)? Can nslookup resolve the IP address back to the name?
> These certain internal hosts - what are they? Could it be that you dont have
> an AD integrated DNS and on of the DNS servers is unable to resolve the
> questionable host names?
> Use nslookup connect parameter to select the other DNS servers, if they work
> as well.
> With multiple DNS servers you don't have influence, which one the client
> selects for name resolution finally. So may be it works, if you enter only
> one DNS server, which knows these hosts, while with DHCP another DNS server
> is queried which is unable to resolve the questionable names.
> Check also that there are no manual additions of extensions to other/old/non
> existent domains somewhere in the TCP/IP properties.
> Best greetings from Germany
> Olaf
>

Hi Joe,
"Joe" <(E-Mail Removed)> wrote in message
news:0146F2A4-D95E-441D-826B-(E-Mail Removed)...
> Thanks again for responding. I know this particular problem is going to
> be
> resolved in the details, so here are the answers to your questions.
> Your thoughts are appreciated.

sorry for coming back late - somehow after reinstalling my PC after a
motherboard outage Windows Mail did hide the postings from me ...
Your answers seem to implicate, that your DNS has no problems. So the
chances are there in other name resolution mechanics.
Did you check on client side, if there are outdated entries in HOSTS or
LMHOSTS files in Windows\System32\drivers\etc?
Also a view into the WINS server database for outdated stuff may pay out.
Otherwise I'm out of ideas, as long as no rouge DNS server takes over.
Best greetings from Germany
Olaf

Olaf,
Thanks for getting back to me. I've had little input on this problem and
your thoughts are greatly appreciated.

We do have some entries in the HOSTS file on some laptops, but since the
primary problem is with a new host, there should be no conflict with any
existing HOSTS file entry. Also, no workstations have HOSTS file entries and
they are being affected as well.

We don't use an LMHOSTS file, although the TCP/IP settings are set to
'enable LMHOSTS lookup.' Is there a possible conflict here? I've only used
LMHOSTS once, years ago, and don't recall how it relates to DNS.

We do use WINS, but I've checked all 4 WINS servers and found no reference
to either the host name or IP address in question.

So, unless this information sparks something on your side, I'm out of ideas
as well.
Thanks,
Joe

"Olaf Engelke [MVP Windows Server]" wrote:

> Hi Joe,
> "Joe" <(E-Mail Removed)> wrote in message
> news:0146F2A4-D95E-441D-826B-(E-Mail Removed)...
> > Thanks again for responding. I know this particular problem is going to
> > be
> > resolved in the details, so here are the answers to your questions.
> > Your thoughts are appreciated.
>
> sorry for coming back late - somehow after reinstalling my PC after a
> motherboard outage Windows Mail did hide the postings from me ...
> Your answers seem to implicate, that your DNS has no problems. So the
> chances are there in other name resolution mechanics.
> Did you check on client side, if there are outdated entries in HOSTS or
> LMHOSTS files in Windows\System32\drivers\etc?
> Also a view into the WINS server database for outdated stuff may pay out.
> Otherwise I'm out of ideas, as long as no rouge DNS server takes over.
> Best greetings from Germany
> Olaf
>
>

Hi Joe,
"Joe" <(E-Mail Removed)> schrieb im Newsbeitrag
news1E8B25E-C49B-4BBF-9357-(E-Mail Removed)...
> We do have some entries in the HOSTS file on some laptops, but since the
> primary problem is with a new host, there should be no conflict with any
> existing HOSTS file entry. Also, no workstations have HOSTS file entries
> and
> they are being affected as well.
>
> We don't use an LMHOSTS file, although the TCP/IP settings are set to
> 'enable LMHOSTS lookup.' Is there a possible conflict here? I've only
> used
> LMHOSTS once, years ago, and don't recall how it relates to DNS.
>
> We do use WINS, but I've checked all 4 WINS servers and found no reference
> to either the host name or IP address in question.
>
could it be, that the names of these machines are being tried to resolve via
NetBIOS instead of DNS?
In this case it should help, to create manual entries in the WINS servers,
pointing to these machines. (I just today figured out, that access to an
Unix server via NFS in Windows Server 2003 R2 failed from one day to another
after taking down the old WINS server, which did include a manual reference
to that machine. The new WINS server didn't have an entry, DNS didn't
resolve the short name, since the Unix domain is another one, so it was not
found. The same for some print servers.)
Best greetings from Germany
Olaf

Olof,
Well that is certainly the most solid idea I've heard yet. I will give it a
try, although it will take a week or two to schedule it since it impacts
production.

Thanks for all your help. I will try to post my results here as soon as I
have them.

Cheers,
Joe


"Olaf Engelke [MVP Windows Server]" wrote:

> Hi Joe,
> "Joe" <(E-Mail Removed)> schrieb im Newsbeitrag
> news1E8B25E-C49B-4BBF-9357-(E-Mail Removed)...
> > We do have some entries in the HOSTS file on some laptops, but since the
> > primary problem is with a new host, there should be no conflict with any
> > existing HOSTS file entry. Also, no workstations have HOSTS file entries
> > and
> > they are being affected as well.
> >
> > We don't use an LMHOSTS file, although the TCP/IP settings are set to
> > 'enable LMHOSTS lookup.' Is there a possible conflict here? I've only
> > used
> > LMHOSTS once, years ago, and don't recall how it relates to DNS.
> >
> > We do use WINS, but I've checked all 4 WINS servers and found no reference
> > to either the host name or IP address in question.
> >
> could it be, that the names of these machines are being tried to resolve via
> NetBIOS instead of DNS?
> In this case it should help, to create manual entries in the WINS servers,
> pointing to these machines. (I just today figured out, that access to an
> Unix server via NFS in Windows Server 2003 R2 failed from one day to another
> after taking down the old WINS server, which did include a manual reference
> to that machine. The new WINS server didn't have an entry, DNS didn't
> resolve the short name, since the Unix domain is another one, so it was not
> found. The same for some print servers.)
> Best greetings from Germany
> Olaf
>