1

Is there a way to manually set what IP address/DNS record AD will use when replicating?

I have a "network within a network" (NWaN) setup which spans across two remote locations-- so there's one NWaN at Site A, then there's an IPsec tunnel connecting it to the second NWaN at Site B. The addressing's like this:

ServerDC1 (at Site A)

NIC1: 1.1.1.1/24 -- This is accessible from all internal networks, and can reach the internet.

NIC2: 1.2.1.1/24 -- This is a private, internal network, and can only be reached from the 1.2.1.x/24 subnet.

ServerDC2 (at Site B)

NIC1: 1.1.1.2/24 -- This is accessible from all internal networks, and can reach the internet.

NIC2: 1.2.1.2/24 -- This is a private, internal network, and can only be reached from the 1.2.1.x/24 subnet.

ServerDC1 and ServerDC2 are both DNS servers meant to replicate to each other, but they each contain DNS records for themselves and all the clients they deal with on both the 1.1.1.x/24 and 1.2.1.x/24 networks.

This creates a problem, as whenever I try to replicate between these two servers, they try to communicate using their nonroutable 1.2.1.x addresses rather than their 1.1.1.x address.

I can go through the DNS records on both servers and delete the references to the 1.2.1.x associated with these servers and then they'll replicate fine; but I'm not sure if any machines will need these records.

So is there a way I can tell AD to only use the 1.1.1.x address when replicating?

I've looked into split DNS, but I can't afford the downtime that it would require.

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
ProfessorJV
  • 13
  • 5
  • 2
    Oh man, this is only going to be the start of your nightmares. A shared AD infrastructure means that you're going to have ton of A records in your DNS that are just going to be pointing to the wrong place. Update an A record on Site A and Site B will get the same record, but that IP is likely to be for a totally different service. Renumber one of those networks as soon as you practically can! You can't even set up Active Directory Sites and Services properly, because that uses subnets to infer the site. – Mark Henderson Nov 25 '15 at 18:24
  • @MarkHenderson Good catch on the multihome perils! I didn't even notice that because I've never seen in the wild. ProfessorJV, you're definitely going to want to renumber one of the locations to something else. You DNS records are going to be a huge pain, and you also have to know the limitation of your broadcast domains in this case - unless you are forwarding broadcasts over your site-to-site link, in which case you will have lots of other problems. Godspeed in renumbering on of those networks! – TheGrandPackard Nov 25 '15 at 18:39
  • The main problem here, apart from the multihoming, is that you are using the same subnet on both sites; you just *can't* properly handle replication (and local DC discovery) if AD can't tell tell which site a DC belongs to. – Massimo Nov 25 '15 at 18:45
  • 1
    Another problem you're going to have is that if you have domain clients on both subnets then you need each DNS server to listen for client queries on both subnets and a Windows DNS server will register an A record for each interface it's bound to and listening on... so even if you deleted one of the A records the DNS server would just register it again. – joeqwerty Nov 25 '15 at 18:48
  • Can confirm, this has also been a problem, albeit a less crucial one. – ProfessorJV Nov 25 '15 at 19:13
  • 1
    It wouldn't be that bad if you did not need to serve AD clients on the 1.2.1.n network. It isn't uncommon to have a dedicated network adapter for backups/out of band management. AD can be configured to not register that IP address in DNS, and you could even unbind the Client for Microsoft networks from it. However, even in that case, multi-homed domain controllers can exhibit inconsistent behavior. – Greg Askew Nov 25 '15 at 19:29

2 Answers2

4

This is probably not what you want to hear, but this is why firewalls and routers were invented. This sort of network design is basically the anti-christ and breaks a fundamental building block of TCP/IP and, for that matter, Active Directory.

The correct thing to do here is:

  1. Re-number one of those sites to a different subnet (say, 1.3.1.0/24).
  2. Stop multi-homing your DCs. Have your DCs only sitting on the internal network
  3. Link your two networks via a router. One router will have 1.1.1.0/24 and 1.2.1.0/24 and the other router will have 1.1.1.0/24 and 1.3.1.0/24
  4. Set up your Active Directory Sites and Services to define your subnets as appropriate. Your AD infrastructure does not need to know anything about your 1.1.1.0/24 network as that's now purely for transit

The setup as you have it now is just going to cause you many, many headaches, such as:

  1. Authenticating against a non-local domain controller
  2. Domain controllers registering their IPs in the DNS that seem to be accessible from both locations, but in fact are not
  3. DHCP leases going into the DNS that appear to be accessible, but are not
  4. Clients trying to access services that are published in the AD (e.g. Exchange) that appear to be contactable, but are not
  5. omg just no
Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
  • That "omg just no" really is all there's to say on the matter. – Massimo Nov 25 '15 at 18:43
  • That _looks_ more pleasant to deal with. I'll probably just stop touching it for the time being... there's very little to replicate: No users, rarely a new machine, these servers just host software that's transferring data. Eventually (and hopefully), we'll get the new firewall up and reconnect the 1.2.1.x/24 between site A and B. If this happens, do you see this being a less problematic setup? I'm not well versed on multi-homed DCs (I'll read up on it). I'm more of a network engineer; been a long time since I studied AD/Server. – ProfessorJV Nov 25 '15 at 18:48
  • @ProfessorJV just make sure they replicate at least once before the tombstone lifetime is up. Normally it's 180 days. But yeah, it'll be so much easier to have a properly routed network. – Mark Henderson Nov 25 '15 at 18:50
  • 1
    Got it. Thanks again. It's very clear now why this has seemed so impossible... it is! – ProfessorJV Nov 25 '15 at 18:52
1

In the Active Directory Sites and Services MMC you can specify a manual replication topology instead of the automatic topology that is generated as Domain Controllers are added to the domain.

Open up Server Manager > Active Directory Sites and Services. You will see your domain listed and below that is a folder titled Inter-Site Transports and IP under that. You have to drill down but you will eventually see the site links.

If you do not see as many site links as you'd expect, you may not have all of your sites correctly set up in this MMC, in which case you will need to specify them and allow that to replicate before changing the links.

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
TheGrandPackard
  • 206
  • 1
  • 10
  • The IP folder only contains "DEFAULTIPSITELINK" right now. I'll play around with trying to get my DCs in here. Thanks – ProfessorJV Nov 25 '15 at 17:27
  • One of the problems you're going to have @ProfessorJV is that you can't define your sites properly, because you have the same subnet in both locations and multi-homed DCs. Multi-homed DCs are normally a no-no. Whilst they can be made to work, it's usually not worthwhile. But multi-homed where each DC sees the same two subnets when they're actually different subnets? That's wayyyyy out there in terms of deployments. – Mark Henderson Nov 25 '15 at 18:29
  • Haha, the way you worded the situation makes it quite clear how bizarre this setup is. It's (hopefully) temporary until we install our new firewall, which will reconnect the 1.2.1.x/24 networks (I'm told it all used to be one network in the past...) – ProfessorJV Nov 25 '15 at 18:35
  • @ProfessorJV That certainly would make sense, if they used to be a joined network. Well, it makes sense in terms of I can see *how* this happened, not that it makes sense in any other sense of the word. – Mark Henderson Nov 25 '15 at 18:41