This is difficult to explain, so bear with me.

We have 2 domain controllers, each multi-homed to straddle 2 internal subnets, (subnet A and subnet B) and provide dns, dhcp, and ldap authentication.

Both domain controllers each have 2 DNS entries. both entries have identical host names, but correspond to subnet A & subnet B respectively (example entries shown):

dc1 host

dc1 host

dc2 host

dc2 host

We also have a 3rd subnet for our dmz, (subnet C) which neither domain controller has an IP address on, but our firewall/routing tables provide access to subnet A from subnet C and vice versa, but don't allow access to subnet B from subnet C.

Here's my issue. How can I force/determine which dns entry is used when a server on subnet C queries either domain controller by host name? Right now it seems to randomly pick one of the two entries, swaps out the name for the IP address and that's that.

The problem is if it randomly selects the entry that corresponds to the 9.x subnet B (no access from subnet C), then the server fails to resolve. If it picks the entry for the 8.x subnet A then it resolves (firewall/routing tables defined for communication between these 2 subnets)

Here's what I'd like to know:

  • What are Best Practices (if any) for dealing with DNS resolution on subnets that the DNS servers don't have a presence on?
  • Can I control something akin to a metric value to force an order of DNS resolution when there are multiple entries for the same host name that correspond to different IP subnets?
  • Should I even have 2 DNS HOST entries for the same name?

Here's what I'd like to avoid:

  • Making edits to the HOSTS files of servers on subnet C to force DNS resolution of the hostname to the appropriate subnet
  • Adding NIC's to the DC's to have them straddle the DMZ as well, thus obtaining a third DNS entry that corresponds to subnet C

Again, my apologies if this was too verbose / unclear.



At the risk of not answering your question - I don't understand the need to multihome your DCs - just put them on their own subnet (VLAN is better) which is routable from any subnet that needs it. This avoids the split DNS issue completely.

I agree with @Ed Fries' comment about setting up sites - this was my initial thought as well - if you had to keep the same network topology then it is perhaps a suitable way of doing things.

Still ditching the multi homing would be my preferred (and as Ed points out MS's recommended) method.

  • 1
    Agreed, or put 1 DC in subnet A & B and create sites in AD. Microsoft strongly discourages multi-homed DC's. If you need redundant links between subnets then provide them but don't multi-home DC's. social.technet.microsoft.com/Forums/en-US/winserverDS/thread/… – Ed Fries Mar 9 '10 at 0:39
  • 1
    I agree as well. Put one DC on each subnet, set them up in ADS&S and be done with it. – joeqwerty Mar 9 '10 at 2:46
  • Sounds good. There is no reason to multi-home the servers. I'll just pull out the NIC's on subnet B. As for ADS&S, would I need to use it if I just retired one of the NIC's? Is there any good literature out there to breakdown ADS&S so I can learn more about it? – I.T. Support Mar 9 '10 at 16:25
  • The caveat to this was we needed to enable a DHCP relay agent on our firewall to allow clients on subnet b to reach out to the DHCP servers on subnet a. Once that was enabled we resolved the issue – I.T. Support May 20 '10 at 19:14

I suspect the OP's multi-home setup is an attempt to resolve issues with either DHCP or Wins.

  • The multi-home setup was inherited, I'm merely trying to assess the best way to fix the issues it's introducing into the network. – I.T. Support Mar 9 '10 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.