Win2K3 R2 x64 SP2 DNS & name resolution problem.

[Guest Chuck Chopp]

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?

[Guest Bill Grant]

Re: Win2K3 R2 x64 SP2 DNS & name resolution problem.

 

You should not multihome your DC/DNS servers. This will always cause

you grief.

 

Simply run the machines in one network with one NIC each. To access the

corporate network and\or the Internet, run one vm (not a DC) as a router

between the virtual LAN and the physical LAN. Running a NAT router will give

the machines on the virtual network access to the physical LAN and the

Internet but it will not expose them to the physical network.

 

Set all machines on the virtual network to use the local DNS service and

configure that local DNS to forward to the corporate DNS (or some other

public DNS service).

 

"Chuck Chopp" <ChuckChopp@rtfmcsi.com> wrote in message

news:e3bi$z35IHA.4352@TK2MSFTNGP03.phx.gbl...

> 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?

>

>