RE: [ActiveDir] DDNS in Unix environment

[Willem Kasdorp]

Guy,   Those are good points by Al. Especially the DNS TTL will break you up if the customer expects a quick failover. I would expect that there is some mechanism in the cluster failover (a script hook or something) that will allow you to manually change DNS where needed. But is this really the way to go? I’d take a hard look at how the app is supposed to realize high availability. Additionally, I have seen a similar scenario where a redundant network loadbalancer would reroute traffic to the active node. That would take care of name resolution and similar issues, anyway.   --     Cheers, Willem   (disclaimer: I know nothing about Veritas HA clusters)   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Monday, June 19, 2006 4:01 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] DDNS in Unix environment   Guy, can we assume that the requirement is to provide the high availability as transparently as possible then? What is the expectation if the primary site goes away as far as client name res? What is their way of knowing that the server went away and to use a new name (keeping in mind that caching etc is going to take place)? What does Veritas recommend? (it is there product after all).   Al   On 6/17/06, Guy Teverovsky <[EMAIL PROTECTED]> wrote: Howdy all, I am banging my head over this trying to come up with a solution for a client. To make the long story short: financial organization which is very concerned about security. They are setting up a new network segment that will be serving some application to the internal network (there is a firewall in between). Because of the critical nature of the application, there is a DR site. AD is used for authentication and DNS. There is a Veritas HA cluster serving the application that will fail over to DR site in case the primary site goes down. Primary site: 2 DCs with SFU (R2) + Veritas cluster node DR site: 2 DCs with SFU (R2) + Veritas cluster node. Primary and DR site are at different physical locations and on different subnets. The only problem with this setup is that the cluster needs to register it's DNS name when failing over to DR site and it does not support secure DDNS. The best thing it can do is T-SIG DDNS with pre-shared key. Enabling non-secure DDNS is not an option. I can disable the DNS registration requirement in the cluster resource group, but this has some issues, while one of them is the fact that accessing the application at the DR site (from internal LAN) will require using FQDN different from the FQDN of the primary site. An alternative would be to somehow enable DDNS only from a predefined set of IP addresses, but from what I know the MS DNS is not capable of it (correct me if I'm wrong). Switching to BIND presents the same issue: while it can solve the dynamic registration of the cluster service using T-SIG DDNS, yet non-secure registration of SRV records is not acceptable and I would like to avoid having statically registered SRV records for the DCs. Not sure whether the solution is in the MS DNS, but there are some knowledgeable folks over here that might have stumbled upon something like this. Any help is greatly appreciated. Thanks, Guy