Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
The HOSTS file absolutely will "take precedence" for forward resolution of names to IP addresses. AD authentication uses SRV RR's to "find" LDAP servers (via the _LDAP SRV RR), and a HOSTS file can't "fake" SRV RR's. –  Evan Anderson Jul 9 '09 at 7:31
    
Thank you Evan.The reason I cannot use Windows DNS is company policy.Windows domains are managed by central team and I suspect that if I set up Windows DNS in DR site I would need to have it trusted by central DNS servers? –  Sergei Jul 9 '09 at 7:34
    
I added info to my question: "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 SPNs" –  Sergei Jul 9 '09 at 7:36
    
It sounds like you need to work a political angle on this more that a technical angle. Using Windows DNS in the DR site is going to provide the best possible (most efficient, fastest to deploy, most "supported" by Microsoft) situation. I'd consider working through management to determine how best to align "company policy" with the needs of the business w/ respect to DR. This isn't a technical problem, per se. Microsoft's Active Directory product works most readily with Microsoft's DNS server. If that's what you're using in production, it behooves the company to use that in DR, too. –  Evan Anderson Jul 9 '09 at 7:37
    
Excuse my ignorance, but if hosts file does not have SRV RR, would not be they looked in the next p referenced place , DNS server? –  Sergei Jul 9 '09 at 7:38

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.

share|improve this answer
    
Thank you John.Will need to bit of time to digest it :) –  Sergei Jul 9 '09 at 7:42
    
"NB for Windows file sharing to work..." ? Remember, it's not a race. Evan Anderson is up 24 x 7 x 365, and types wicked-fast. >smile< –  Evan Anderson Jul 9 '09 at 7:42
    
Ok , my brain is heating up here.Let' say I have windows AD domain called my.domain.com . What what would be non - AD integrated domain you suggested - my.domain.com.site? –  Sergei Jul 9 '09 at 7:51
    
@Evan: I know you're really just an usually advanced AI program running on a Mac, but you're secret's safe with me :-) I've edited my comment and hopefully clarified it a bit. –  John Rennie Jul 9 '09 at 7:59
    
@Sergei: it doesn't matter what you call the domain. I always use something.site so I know at a glance it's a domain I've created for this purpose i.e. a site specific domain. The name need not be related to your AD domain or indeed anything else. –  John Rennie Jul 9 '09 at 8:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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