DC can't resolve names on remote subnet

[mike i]

Hello,

I have a relatively simple network with two domain
controllers (with integrated DNS) on subnet A and 3 win2k
servers on subnet B. The problem is that the DC's on
subnet A can not resolve the server names on subnet B.
The servers on subnet B, however, can resolve all names on
both subnets. The router is configured to forward all
traffic, and subnet A servers CAN ping the subnet B
servers (in fact, I can map drives as well, as long as I
use IP addresses instead of names).

Any ideas would be appreciated.

Thank you,
Mike

 

[Ace Fekay [MVP]]

In

Hello,

I have a relatively simple network with two domain
controllers (with integrated DNS) on subnet A and 3 win2k
servers on subnet B.

The problem is that the DC's on
subnet A can not resolve the server names on subnet B.

The servers on subnet B, however, can resolve all names on
both subnets.

The router is configured to forward all
traffic, and subnet A servers CAN ping the subnet B
servers (in fact, I can map drives as well, as long as I
use IP addresses instead of names).

Any ideas would be appreciated.

Thank you,
Mike

How are you trying to ping? By FQDN or by NetBIOS names?

If NetBIOS names, then it's a NetBIOS resolution issue and would suggest to
look at your WINS configuration.

If FQDN, then assuming this is all ONE domain, since you mentioned your
zones are AD Integrated on each DC/DNS server, then I don't see why you're
having this sort of problem. Unless....you are using your ISP's DNS
addresses in your machines' IP properties....We all know this is a big NO-NO
with AD.

Can you elaborate a bit more? Thanks.



--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[mike i]

Neither FQDN nor NetBIOS names work for pinging or
anything else. As far as the details of the network,
here's the overview:

Subnet A: Internal network with private IP addresses. 2
win2k DC's with with AD integrated zones. Both DC's are
in the same domain. Neither of the servers can browse the
resources on Subnet B, nor ping them by name.

Subnet B: DMZ with 3 win2k servers. Different private IP
network. The firewall serves as the router between the 2
networks, but the policy allows all traffic between Subnet
A and Subnet B. All 3 servers in this subnet are member
servers of the same domain as the DC's on Subnet A. All 3
servers can browse the resources on the DC's and ping the
DC's by name (FQDN and NetBIOS). In fact, all 3 were able
to join the domain from Subnet B.

IP properties: All servers have static IP's. The first
DNS server listed is the first DC. The second is the
ISP's DNS server. However, even if the ISP's DNS server
is taken out, the problem persists.

 

[Ace Fekay [MVP]]

In

Neither FQDN nor NetBIOS names work for pinging or
anything else. As far as the details of the network,
here's the overview:

Subnet A: Internal network with private IP addresses. 2
win2k DC's with with AD integrated zones. Both DC's are
in the same domain. Neither of the servers can browse the
resources on Subnet B, nor ping them by name.

Subnet B: DMZ with 3 win2k servers. Different private IP
network. The firewall serves as the router between the 2
networks, but the policy allows all traffic between Subnet
A and Subnet B. All 3 servers in this subnet are member
servers of the same domain as the DC's on Subnet A. All 3
servers can browse the resources on the DC's and ping the
DC's by name (FQDN and NetBIOS). In fact, all 3 were able
to join the domain from Subnet B.

IP properties: All servers have static IP's. The first
DNS server listed is the first DC. The second is the
ISP's DNS server. However, even if the ISP's DNS server
is taken out, the problem persists.

Hi Mike, thanks for posting that additional info.

THe first and MAIN thing I would do is immediately remove the ISP's DNS
addresses. This is paramount for a proper funtioning AD. I can provide a few
links on this, but you can read/search thru these newsgroups and you can see
the consensus on this. Just use your internal DNS servers ONLY (this goes
for the DCs and clients as well) and configure a forwarder. If the
Forwarding option is grayed out, delete your Root zone and refresh the
console and try again. This article shows these two steps: Keep in mind,
each DNS needs to be forwarded individually to the ISP. So this has to be
done on all DNS servers. Do not forward to each other.
http://support.microsoft.com/?id=300202

As for IP properties in your DC/DNS server, it's recommended that the first
should point to it's partner, and the second entry to itself. That relieves
a couple issues.

Ok, that stated, now let's take a look at your DC/DNS servers. Since they
are AD Integrated zones, that's good. I want to suggest to put one in the
DMZ, but it's not necessary. Since B (the DMZ) can access A, but not the
other way around, I am curious if there is any Event errors showing up? I
have a feeling that it's either there is a rule blocking traffic in one
direction but not the other. I am curious if there is any MTU modifications
or an H.323 optimization going on (which is default in scenarios such as
this). For example, under many router manuf, when there are mutliple NAT'd
private IP interfaces, traffic between the subnets may be squelched to a
degree. The biggest problem I've seen is H.323 traffic being optimized,
which causes a problem with LDAP communication. LDAP uses a PDU (process
data unit) sixe of 300k, but H.323 uses 64k. SO what we usually do, say if
this were a W2k server, we disable H.323 support, which then LDAP will
communicate. In some router brands, I've seen MTU optimizations for video
conferencing (H.323) and were set below 1500bytes (such as 1460). Once put
back to 1500 bytes, the problems go away.

In summary, take care of and clean up the DNS settings on all your machines
first, please. This may all be a simple issue of DNS resolution. Believe me,
using an external (such as an ISP), *WILL* caused numerous issues. All you
have to do is search back thru these posts to see what I mean. I'm leaning
towards that is being the problem and second, torwards the router. It may
also be a combo of the two. I don't think it's an MTU issue at this point.

Remove those ISP's from your DCs and member servers and clients and let us
know how you make out.


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

 

[mike i]

Thank you. I do have a question, though. We had to move
one of the member servers from the DMZ (subnet B) to the
Internal Network (subnet A) in order to make it work.
Currently, DC1 and Server1 are in production and I
wouldn't want to disturb them. I can make changes to DC2
and Server2 though. I already tried removing all
references to the ISP's DNS server, as well as DC1, on
DC2, but it still won't resolve Server2 on the remote
subnet. I even removed all ISP and DC1 references on
Server2, pointed it to DC2 and registered dns on it, but
DC2 still won't resolve Server2.

Is there anything else I can try at this point without
disturbing production on DC1 and Server1? I will probably
have to wait until the weekend to make serious changes to
the production environment.

 

[Ace Fekay [MVP]]

In

Thank you. I do have a question, though. We had to move
one of the member servers from the DMZ (subnet B) to the
Internal Network (subnet A) in order to make it work.
Currently, DC1 and Server1 are in production and I
wouldn't want to disturb them. I can make changes to DC2
and Server2 though. I already tried removing all
references to the ISP's DNS server, as well as DC1, on
DC2, but it still won't resolve Server2 on the remote
subnet. I even removed all ISP and DC1 references on
Server2, pointed it to DC2 and registered dns on it, but
DC2 still won't resolve Server2.

Is there anything else I can try at this point without
disturbing production on DC1 and Server1? I will probably
have to wait until the weekend to make serious changes to
the production environment.

No prob for the info., Mike. The only thing I can see if it can't resolve
it, is if there is no host entry for Server2 in DNS under the zone, which
I'm assuming you've already verified that.

Other than that, I'm tending to lean towards your firewall being the issue.
I helped a guy out back in Feb this year who had problems with two DCs not
replicating between each other, one here in the US, the other in another
country. It was working fine until (after asking numerous questions) that he
had upgraded the firmware on his Sonicwall. APparently the upgrade bumped
the MTU down and it was the cause of the whole thing. So after dealing with
that for 3 days before figuring it out (because everything else looked clean
at the time), I always question the router/firewall for rules or settings,
whehter default or altered.

Hope that gives you a start...Good luck.


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory