3

We have 6 different AD sites all connected by IPSec tunnels in a full mesh aside from one office which cannot connect to our data centre for stupid ISP related reasons that are not fixable currently. We have AD integrated DNS and there are two web servers, with public IPs, which replicate the internal address across our AD sites and are accessed via the IPSec tunnels. Since both of these servers are in our DC the site which cannot connect to the DC is unable to access both of these sites.

We need to replicate the rest of our AD DNS to this site, so removing replication is not an option. These sites are also in our primary domain's DNS, and updating them to either use an alternate name, or alternate domain suffix is not a viable option as it will break links for this office.

Is there a way to have this one site use alternate DNS records and not replicate those across AD?

Is my best option to GPO all client/server computers in that site to add the public IP for these two hosts to the local hosts file?

This doesn't need to be a permanent, elegant fix as we will be changing ISPs soon(ish). I just need something that will be stable and reliable for this office for the mid-term future. Simplified Network Diagram

To clarify: Toronto and New York can talk to Tokyo, each other and the data centre. Tokyo can talk to Toronto and New York, but not the data centre. We have resources in each site, as well as AD replication, that need to be accessed from all the other sites.

Two of these resources are in our data centre, and have public IPs as well as internal IPs, and use the same hostname internally and externally. That hostname is integrated into our Active Directory DNS. All access from New York and Toronto to these sites is done via the internal IP addresses.

We need Tokyo to access these two hosts via their public IP, not their internal one. We cannot use different hostnames as these sites are heavily integrated into our other applications, communications, etc.

Improve this question
6
  • So users usually connect to these sites using their internal DNS names then? Why not give them names in your external DNS and have the users in the isolated site use those names to connect?
    – joeqwerty
    Sep 9, 2015 at 18:26
  • AD DNS should only be for internal addresses. If the tunnels won't work for this site, those machines won't be able to access the internal resources anyway. What benefit could you possibly get from replicating AD DNS? Does each individual machine have it's own vpn?
    – Joel Coel
    Sep 9, 2015 at 18:33
  • The web servers have public ip addresses, so the clients in the isolated site can access them over the internet, not through the tunnel. All other AD replication happens via other sites, which the isolated site does have access to. The only issue is accessing the web servers in the DC via their internal names and ip addresses because no tunnel exists. Give the web servers names in the external DNS zone and have the isolated clients access them by those names. This one isn't as complicated as it sounds at first blush. Of course, I've assumed all of that.
    – joeqwerty
    Sep 9, 2015 at 18:42
  • @joeqwerty all other sites connect using internal DNS. The same DNS names are in our public DNS (eg: www is 192.168.1.10 internally and 22.22.22.14 externally) If I could set the internal DNS for the one site to the external DNS and not have it replicate that would be perfect. We can't have users in the isolated location access the sites via different names as they're heavily integrated into applications, communications etc. So asking them to go to www2.* instead of www.* will work for direct access, but not within applications that link to those sites.
    – RobbieCrash
    Sep 9, 2015 at 18:46
  • Oh, gotcha. disregard my comments then.
    – joeqwerty
    Sep 9, 2015 at 18:53

2 Answers 2

Reset to default
2

If I am understanding your question correctly, you need two DNS servers in two different locations to answer the same query with two different responses, each one specific to its location; this record is located in an AD-integrated zone which is replicated on both DNS servers, and you would like to turn off replication only for this record, so that you can hand out different answers from different servers.

If this is the case, your solution is to create a subdomain instead of an A record, and configure it as a primary zone on both servers, without AD integration; then on each zone create an unnamed record pointing to the correct IP address; an unnamed record answers to requests for the zone name, thus it will be effectively equivalent to an A record in the top-level zone.

Example:

Your domain is domain.local; this is an AD-integrated zone.
Your DC/DNS in Site 1 is called DC1. Your DC/DNS in Site 2 is called DC2. Your record is server.domain.local; you need it to point to 10.20.30.40 if requested to DC1, but you need it to point to 192.168.90.42 if requested to DC2.

  • Create a standard primary zone on DC1 for the (sub)domain server.domain.local; then, in this zone, create an unnamed A record pointing to 10.20.30.40.
  • Create a standard primary zone on DC2 for the (sub)domain server.domain.local; then, in this zone, create an unnamed A record pointing to 192.168.90.42.

This way, when DC1 is asked for server.domain.local, it will answer with 10.20.30.40; if the same query is made to DC2, it will answer with 192.168.90.42.

Improve this answer
9
  • Creating the zone on DC1 is probably unnecessary as DC1 clients don't have this issue and an answer from the domain.local zone will resolve correctly for them without the need of the additional zone. Seeing as the web servers are domain members, they'll register themselves in the AD integrated DNS zone, so will this solution over-ride the A record that exists in the AD integrated zone?
    – joeqwerty
    Sep 9, 2015 at 20:42
  • You need to create a zone on DC1 too, because it you create a standard A record, it will get replicated to DC2 through AD replication; if you instead create a non-AD-integrated zone, this will not get replicated and you can create a different zone with the same name on DC2.
    – Massimo
    Sep 9, 2015 at 20:51
  • It's a bit of a chicken or the egg problem. The A records already exists in the AD zone and will be automatically registered in the AD zone by the web servers because they're domain joined machines, so how do you deal with that when creating the new zone? You would need to stop the automatic registration of the A records in the AD zone and then create the new zone on both DC's. Or would the web servers register in the new zone from that point on?
    – joeqwerty
    Sep 9, 2015 at 21:09
  • I was assuming the A record didn't match the name of a specific server; however, if it does, then yes, this introduces a little complexity; but this can be solved by deleting the existing record, creating the new child zones (each one with its unnamed record) and configuring them to not allow automatic registration.
    – Massimo
    Sep 9, 2015 at 21:14
  • 2
    Right, I'm just mulling things over for myself...
    – joeqwerty
    Sep 9, 2015 at 21:28
0

You could do the following:

  1. Create a new DNS Application Directory Partition.
  2. Limit the replication scope of the Application Partition to only those DC's that need the override.
  3. Create a new forward look-up zone in the new Application Partition.
  4. Create a blank record in the zone for the override.

I have honestly never had to do this, but it seems like the way to pursue what you specifically asked. Test it.

Of course, this is a bit hackey. Can you post a diagram or something like that? I have a feeling that there is a simpler answer.

Improve this answer
4
  • 1
    Added a diagram and a bit of clarification.
    – RobbieCrash
    Sep 9, 2015 at 19:20
  • "Tokyo can talk to Toronto and New York, but not the data centre." What is stopping you from creating routing rules in NY and Toronto to allow Tokyo transit into the Datacenter?
    – Joseph Kern
    Sep 10, 2015 at 10:04
  • Cisco and Juniper routers don't like to do that together. When trying to route multiple subnets over one tunnel the tunnel refuses to come up due to proxy ID/Policy mismatches. We worked with Cisco and Juniper to resolve but weren't able, it seems to be a limitation in ScreenOS (the low end Juniper OS).
    – RobbieCrash
    Sep 10, 2015 at 18:56
  • hahah ouch. Looks like you do need a quick and dirty solution then. I bet you've been pulling your hair out. Sounds like the GPO for the hosts file is a good interim solution.
    – Joseph Kern
    Sep 11, 2015 at 8:03

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.