First published on MSDN on Jul 17, 2009
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
will be registered against IP addresses
. The ‘Or’ is a dependency which the NetName has on the IP Addresses which implies that
the 172.24.13.99 IPv4 Address
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
will be registered against 2 IPv4 addresses
which are on different subnets. The ‘Or’ is a dependency which the NetName has on the IP Addresses which implies that
the 172.24.13.99 IPv4 Address
the 18.104.22.168 IPv4 Address must come online before the Network Name resources comes online.
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.
System Settings Affecting DNS Registration
There are several settings which can be configured to change the behavior of your cluster.
Primary DNS Suffix
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.
Connection specific DNS suffix
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.
Network Name Private Properties affecting DNS registration
This is the name that will actually be registered in DNS. It cannot be more than 63 characters in length.
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:
This flag indicates whether the corresponding PTR records for the name also have to be published or not.
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.