Guest Chuck Chopp Posted July 16, 2008 Posted July 16, 2008 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 Posted July 17, 2008 Posted July 17, 2008 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? > >
Recommended Posts