Failover Clustering and Network Load Balancing Team Blog
Hi Cluster Fans,
In this post we will discuss some of the implementation details around the Network Name (“NetName”) resource and its behavior in Windows Server 2008 R2.
The purpose of Network Name is to allow clients to be able to resolve the DNS name to an IP Address to establish a connection to it. During DNS registration we present a mapping between the network name and its provider IP addresses over some physical adapter that can reach a DNS server.
Below is an example of a standard Network Name resource. To view this, right click on any network name resource in the Failover Cluster management UI and select “View dependency report”.
In this example, the network name testcno will be registered against IP addresses 172.24.13.99 and 2001:4898:e8:300e:90e3:a1b4:e34c:cbe. The ‘Or’ is a dependency which the NetName has on the IP Addresses which implies that EITHER the 172.24.13.99 IPv4 Address OR the 2001:4898:e8:300e:90e3:a1b4:e34c:cbe IPv6 Address must come online before the Network Name resources comes online.
The entries on the DNS server would look like the following after the registration. To view the DNS entries on your local DNS server, click on Start -> Administrative Tools -> DNS. This will open the DNS Manager GUI.
In a cluster with multiple subnets (such as a multi-site cluster) you may see something like the example below:
In this example, the network name testcno will be registered against 2 IPv4 addresses 172.24.13.99 and 126.96.36.199 which are on different subnets. The ‘Or’ is a dependency which the NetName has on the IP Addresses which implies that EITHER the 172.24.13.99 IPv4 Address OR the 188.8.131.52 IPv4 Address must come online before the Network Name resources comes online.
For more information about resource dependencies, visit: http://blogs.msdn.com/clustering/archive/2008/01/28/7293705.aspx and http://msdn.microsoft.com/en-us/library/aa372236(VS.85).aspx
In Windows Server 2008 R2 we have improved how the DNS registration logic is implemented within the cluster resource DLL implementation of network name resource.
· During network name resource online or immediately after the online:
o The network name resource in an OR dependency is onlined if one or more of its providers is online. Typically an IPv6 address resource comes online quicker than an IPv4 address resource. So during online of a network name resource, the DNS registration for the IPv6 provider happens.
o The registration for the IPv4 provider typically happens immediately after the online.
· If the cluster is idle, the registration is refreshed every 24 hours:
o If the network name group is not moved or there are no new dependencies or there are no changes to the name, then the registration is refreshed only once in 24 hours.
· If an IP address provider dependency is added or removed:
o When a new provider is added or removed for the network name resource, the DNS registration update happens automatically without requiring an offline & online of the resource itself.
In Windows Server 2008, DNS registration behaved slightly differently. If the Network Name had been registered within the last 24 hours, then it would reregister with DNS 10 minutes after coming online. If it had not been registered within the past day, then it is immediately registered when the resource comes Online.
There are several settings which can be configured to change the behavior of your cluster.
When combined with the Host Name this indicates the FQDN of a host. By default it is the same as the Active Directory domain that the host is joined to.
There is a zone on the DNS server corresponding to the Primary DNS suffix of the domain.
The registration for a cluster network name always happens in the zone corresponding to the Primary DNS Suffix of the host.
1. A network adapter can have a DNS suffix that is different from the primary DNS suffix of the host.
In this case, there is a DNS zone on the DNS server corresponding to the connection specific DNS suffix. When the check box “Use this connection’s DNS suffix in DNS registration” is turned on, the DNS registration for the network name also happens in the zone corresponding to the connection specific DNS suffix.
2. Register this connection’s addresses in DNS
If this check box is turned off, the network name doesn’t register in DNS for both the Primary DNS suffix and the connection specific DNS suffix.
3. Dynamic updates
If a DNS zone is set to Secure only, then zone and record permissions come into play.
By default, all Authenticated Users have permissions to create a new record inside a secure zone. But if a record already exists, the security principal (in this case the cluster name identity) should have Full Control over the existing DNS record.
1. DnsName: This is the name that will actually be registered in DNS. It cannot be more than 63 characters in length.
2. HostRecordTTL: This is the Time to Live (in seconds) for the published DNS records. The default is 20 minutes. When a client resolves the name through DNS, its cache will have this TTL. If the TTL value is lowered the client will get DNS records faster. This is useful in a multi-subnet scenario after a cross-subnet failover. With the default behavior, the client may have to wait for up to 20 minutes to receive the DNS record with the updated IP Address, which may prevent them from connecting during this period. If this TTL is reduced, they would receive the updated DNS record faster, and be able to reconnect to the other IP Address faster. This would also result in the DNS servers getting requests more frequently causing more stress on them. Exchange, for example, recommends setting the TTL value to 300 seconds (more information: http://technet.microsoft.com/en-us/library/bb676687.aspx).
3. PublishPTRRecords: This flag indicates whether the corresponding PTR records for the name also have to be published or not.
4. RegisterAllprovidersIP: This flag indicates whether only online provider IPs have to be registered or not. It is useful in a multi-subnet scenario where only one IP Address will be online at a time. If this property is set, when Network Name resource comes online, it will register both IP Addresses (including the offline one). This means that the client’s DNS record will contain both IP Addresses, so after a cross-subnet failover, the client can try connecting to either IP Address, rather than waiting for an updated DNS record which allows the client to reconnect more quickly. The client side of the application needs to be smart enough to handle this i.e. the client side should be able to deal with multiple IPs in the correct manner.
For more information about Powershell for Failover clustering, visit: http://blogs.msdn.com/clustering/archive/2009/05/23/9636665.aspx
Offlining a network name resources does not delete the DNS records on the server. They are only cleaned up when a network name resource is deleted from the cluster.
I hope you found this information useful to understand how Network Name behaves and how it interacts with DNS in Failover Clustering.
Thanks,Sudhir Anantha Padmanaban & Amith Kamath KaupSoftware Development Engineers in TestClustering & High-AvailabilityMicrosoft
Is there a way to disable dynamic DNS for cluster resources? We are using third party DNS (not AD integrated) and dynamic updates are disabled.
I'd like to second the previous comment - what if I just want to disable all dynamic registrations of cluster name resources?
There is a way I have done it, just been trying to find it. It is command line and tells each cluster reseource not to attempt to register with DNS.
Keith, any luck with finding that command?
That command would help me disable the DNS registration as well. Thanks!
The command would really help event viewer from getting flooded by error id 1196
Is there any reason for the PTR record from a cluster standpoint? Does failover clustering or SQL clustering need PTR records, or does that depend only on the application accessing the clustered resource?
<a href="marotravel.com/.../">Paket Pulau Pari</a>
The cluster Network Name resource inherits it's DNS registration logic from the underlying network interface. You can disable the dynamic DNS registrations by unchecking the "Register this connection's address in DNS", see the screen shot in step #1 above.