BIND for Windows domain in DR site

Question

Situation:

• We have DR site that needs to be tested

• There is a mix of Linux and Windows hosts on DR site.In case of disaster if SERVER in production site is not available, SERVER_DR on DR is switched on and joined to the same Windows domain.This is done this way in case primary site is not available and we don't want to delete original record for SERVER form AD.

  The problem I am trying to solve is a name resolution in DR site.Processes and scripts are using DNS name SERVER so in DR site requests to SERVER should translate to SERVER_DR. We have no access to do anything on Windows DNS.

My idea is to use BIND to solve this problem.Hosts in DR should be able to authenticate with AD .Fact that they don't need to access anything else outside the DR site in Windows domain should simplify the problem.

Services that need to be accessed by DR hosts are mostly file sharing and SQL servers.I believe SQL servrers maybe a problem here since they use SPN

This brings an idea of using BIND for our.domain.com zone held by BIND in DR site, however I can see possible problem when Windows DR hosts need to authenticate against AD since they need to use undescored records if I remember correctly.We cannot delegate zones from AD due to the reasons I mentioned earlier.

Is it worth trouble to solve this problem?One of my colleagues suggested using hosts file for each Windows DR host.However it seems pretty ugly there are not many of them and my time setting up BIND may be wasted.

Answer 1

HOSTS files won't make AD authentication work properly. AD authentication needs the SRV RR's that only a DNS server can provide (since a HOSTS file is just A RR's).

Have a look here re: an earlier answer I gave about using BIND to support AD: http://serverfault.com/questions/32605/using-bind9-and-dhcpd-to-support-a-windows-domain

You're going to have trouble with some software working properly if your Windows server computer names are different. Just trying to "alias" the non-DR name to a Windows server with a different computer name set will work for some protocols, but others will fall flat on their faces (SPN's in the AD, for example, are "tied" to computer names).

It's not clear to me why you can't use Windows DNS in the DR site. I would think that you could spin up a Windows DNS server and, if worse comes to worse, delegate the _msdcs.domain.com zone to the Windows DNS server in the existing BIND infrastructure.

I guess I'd need to understand a bit more about what you're trying to accomplish and why you have the restrictions you do, but in general I'd be working to make the DR environment as close to the production environment as possible so that you have a minimal amount of work to do when moving operations into the DR environment.

Answer 2

There isn't an easy way to make hosts on the DR site resolve "SERVER" to the IP address of SERVER_DR while still keeping all the AD DNS stuff working. What you need to do is use an alias for all server references.

My usual approach is to craete a new domain (e.g. mydomain.site) that is not AD integerated. This allows you to use separate and different zone files for different DNS servers. Then change all references to your servers to server.mydomain.site. This allows your users to use a single server name that resolves to whatever is appropriate for the site.

NB for Windows file sharing to work with a CNAME alias you need to add a registry entry for the LanManServer service. See http://support.microsoft.com/kb/281308 for details. This works on W2k8 as well as 2k and 2k3.

I strongly recommend you use the Windows DNS to host the .site domain. If you really can't persuade your sysadmins to help then you could use BIND and configure the Windows DNS servers as fowarders. Then BIND would resolve the .site domain while Windows would be used for all other domains including the AD domain. However this makes things more complex to maintain so I'd avoid it if you can.

JR

PS re "NB for Windows file sharing to work with a CNAME alias"

The point of using the alias is that you can browse shares or map network drives using UNC names like \myserver.mydomain.site\share, where the name "myserver.mydomain.site" resolves to the IP address of your target server, and can resolve to different IP addresses at different sites. By default the LanManServer service won't allow browsing unless the server name matches the real server name, and you'll get an error message something like "A duplicate name exists on the network". This is done to increase security. The KB article I mentioned describes how to turn off the name checking so UNC names like the above work.

Actually I use this trick routinely because it makes it easy to move file shares to different servers. It's not a replacement for DFS but can be a useful trick.