C
Chuck Chopp
Guest
I have a Win2K3 R2 x64 SP2 test environment running under VMware
Workstation v6.03 on a Vista Ultimate x64 SP1 host system with 16 GB of
RAM and 2x Quad-core XEON processors.
There are 2 DCs and 2 member servers. Both DCs are also DNS servers.
Each of the 4 systems has 2 virtual NICs configured. The primary IP
addressing scheme is in the 172.31.x.x/16 network with static IP address
assignment on each NIC, and each system has a NIC that is part of that
network. Those NICs also have the IP bindings configured such that they
register with the DNS servers.
In order for these systems to be able to access the Internet for things
like Microsoft Update, etc..., each system has a 2nd NIC that is
configured with a static IP address in to 10.85.x.x/16 network, with a
default route established that goes thru a NAT-enabled router/firewall.
All outbound 'Net access works just fine.
All NIC's are configured to use the DNS services on the two systems that
are the DCs in my AD test forest, and the DNS service is only listening
on the NICs that have 172.31.x.x addresses. Those DNS servers, in turn,
are configured to forward requests on to other DNS servers that have
access to the Internet and can thus aid in general DNS name resolution
outside of my AD test forest's own name space.
The problem that I'm observing is this:
On a DC, when I attempt to communicate with the local system via IP and
I use it's FQDN, "dc1.cc.ad.cctec.org", utilities like PING and anything
else that does a basic call to gethostbyname() is resolving the name and
returning it's 10.85.x.x/16 address instead of the appropriate
172.31.x.x/16 address. Note, the DNS does not have *any* of the
10.85.x.x addresses configured in any of its zones, nor are there any
such entries in the "hosts" and "lmhosts" files. The "A" records for
"dc1" and "dc2" point to their 172.31.x.x addresses.
If I use nslookup to perform the name resolution, it appears to always
return only the addresses for which "A" records are configured and never
returns the 10.85.x.x addresses. It's only the more general purpose
gethostbyname() [and it's more recent relatives] that appears to cause
this problem.
If I disable the NIC that has the 10.85.x.x address, the name resolution
works properly on that system when it resolves its own name. But, when
I re-enable that NIC, then name resolution goes back to being screwed up
and doing a "ping dc1.cc.ad.cctec.org" results in pinging 10.85.200.1
instead of 172.31.200.1.
I've verified that all zones are "clean" and have no "A" records
pointing to 10.85.x.x addresses. I've flushed my caches, stopped &
restarted the DNS server and DNS client services and even rebooted, but
nothing that I've done affects the problem in any way at all except
disabling the NIC that has a 10.85.x.x address.
Has anybody else encountered this problem? Are there any known
work-arounds or fixes for it?
Workstation v6.03 on a Vista Ultimate x64 SP1 host system with 16 GB of
RAM and 2x Quad-core XEON processors.
There are 2 DCs and 2 member servers. Both DCs are also DNS servers.
Each of the 4 systems has 2 virtual NICs configured. The primary IP
addressing scheme is in the 172.31.x.x/16 network with static IP address
assignment on each NIC, and each system has a NIC that is part of that
network. Those NICs also have the IP bindings configured such that they
register with the DNS servers.
In order for these systems to be able to access the Internet for things
like Microsoft Update, etc..., each system has a 2nd NIC that is
configured with a static IP address in to 10.85.x.x/16 network, with a
default route established that goes thru a NAT-enabled router/firewall.
All outbound 'Net access works just fine.
All NIC's are configured to use the DNS services on the two systems that
are the DCs in my AD test forest, and the DNS service is only listening
on the NICs that have 172.31.x.x addresses. Those DNS servers, in turn,
are configured to forward requests on to other DNS servers that have
access to the Internet and can thus aid in general DNS name resolution
outside of my AD test forest's own name space.
The problem that I'm observing is this:
On a DC, when I attempt to communicate with the local system via IP and
I use it's FQDN, "dc1.cc.ad.cctec.org", utilities like PING and anything
else that does a basic call to gethostbyname() is resolving the name and
returning it's 10.85.x.x/16 address instead of the appropriate
172.31.x.x/16 address. Note, the DNS does not have *any* of the
10.85.x.x addresses configured in any of its zones, nor are there any
such entries in the "hosts" and "lmhosts" files. The "A" records for
"dc1" and "dc2" point to their 172.31.x.x addresses.
If I use nslookup to perform the name resolution, it appears to always
return only the addresses for which "A" records are configured and never
returns the 10.85.x.x addresses. It's only the more general purpose
gethostbyname() [and it's more recent relatives] that appears to cause
this problem.
If I disable the NIC that has the 10.85.x.x address, the name resolution
works properly on that system when it resolves its own name. But, when
I re-enable that NIC, then name resolution goes back to being screwed up
and doing a "ping dc1.cc.ad.cctec.org" results in pinging 10.85.200.1
instead of 172.31.200.1.
I've verified that all zones are "clean" and have no "A" records
pointing to 10.85.x.x addresses. I've flushed my caches, stopped &
restarted the DNS server and DNS client services and even rebooted, but
nothing that I've done affects the problem in any way at all except
disabling the NIC that has a 10.85.x.x address.
Has anybody else encountered this problem? Are there any known
work-arounds or fixes for it?