Helpdesk: "Since the storage maintenance on Saturday, the file server role on the Hyper-V cluster won't stay online on HVN02, and the System log there keeps showing Event 1196: 'Cluster network name resource 'Cluster Name' failed registration of one or more associated DNS name(s) for the following reason: DNS bad key.' There's also a 1257 for FS01. A forum post says to delete the A records, give Authenticated Users full control of the zone, set the zone to accept nonsecure updates, and run Repair. Can we do that?"
Not that way. "Cluster network name resource failed registration" usually isn't a broken cluster. The network name resource asks a DNS server to create or update its A (and optionally PTR) records, from the node that owns the role, with the cluster's identity; it fails when that node asks the wrong DNS server, when the zone won't take the update, when an existing record belongs to an identity the cluster can't act for, or when the computer object behind the name is disabled, missing, or out of sync. The event's reason text tells you which. Microsoft's own guidance for the secure-zone case is narrow: "Ensure that cluster name object (CNO) is granted permissions to the Secure DNS Zone." Its failover clustering blog adds the detail that explains most 1196 and 1257 events after a rebuild or a hand-made record: "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." Opening the whole zone to nonsecure updates fixes the symptom by removing the security that keeps one machine from overwriting another's name. Work through it as a chain: which name, which event, which node → what does the event's reason or error code say? → what does the name resource itself report? → which DNS servers does the owner node ask, and can it reach them? → does the zone accept the update? → who owns the existing record? → is the computer object behind the name healthy? → is time or Kerberos in the way? → change one link → prove every DNS server answers with the right address. Get-WinEvent, Get-ClusterResource, Get-ClusterParameter, Get-ClusterResourceDependency, Get-DnsClientServerAddress, Get-DnsClient, Resolve-DnsName, Get-DnsServerZone, Get-DnsServerResourceRecord, Get-ADComputer, Get-ADObject, and Get-ClusterLog are the sources for that chain. Delete and recreate records "to be safe" and you may hand the name to the wrong owner, break every client that cached the old address, and still see the same event on the next failover.
If the record vanished because DNS scavenging deleted it, DNS Scavenging Not Working covers how aging and timestamps decide that. If a node lists a public resolver because someone wanted the internet to work, Windows DNS Server Not Resolving External Names covers the forwarder side, so the nodes can point only at your own DNS servers. This post covers "a failover cluster network name (the cluster name or a role's client access point) that won't register in DNS: Event 1196 with a reason such as 'DNS bad key' or 'DNS operation refused', Event 1195 with an error code, Event 1257 'access to update the secure DNS Zone was denied', 1256, 1258, 1259, 1260, 1578, 1579, or 1580, a name that resolves to an old address after a failover, or a role that won't come online on one node, and you need a read-first path before you delete records, loosen zone security, or run Repair."
TL;DR
-
Read the reason, not just the event ID. Event 1196 carries the DNS error as text ("for the following reason: %2"), and the name resource keeps the last result in its
StatusDNSparameter, which Microsoft defines as "The returned status code from the last DNS operation that the NetName resource performed." (Steps 2 and 3). - The owner node registers, through its own adapters. The cluster registers "over some physical adapter that can reach a DNS server", so one node with a public or retired DNS server in its list can fail where the others succeed (Step 4).
- The zone is the primary DNS suffix's zone. Microsoft: "The registration for a cluster network name always happens in the zone corresponding to the Primary DNS Suffix of the host." (Step 5).
- An existing record needs the cluster's identity on its ACL. A record created by hand, by DHCP, or by a cluster you've since rebuilt can block the update; read the record's owner before you touch it (Step 6).
- Repair fixes the computer object, not DNS permissions. Microsoft's Repair Active Directory Object is for the cluster name account's password mismatch, and it "will be greyed out unless the cluster's Name resource is offline." (Steps 7 and 9).
-
Re-register without an outage.
Update-ClusterNetworkNameResource"registers existing Network Name resources with a DNS server in a way that doesn't interrupt cluster availability." (Step 9).
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which network name, which event IDs and reason text, which node owned the role at the time, and what changed | "The cluster name is broken" with no event text and no node |
| 2. Event read | The reason or error code is known and mapped to a cause | Event 1196 noted, but nobody wrote down "DNS bad key" or "DNS operation refused" |
| 3. Resource read | The name resource, its IP dependencies, its DnsName, and its last DNS status are known | The name is online with a warning; StatusDNS isn't 0; an IP address resource is offline |
| 4. Node DNS client | Every node's cluster-facing adapters list only DNS servers that host your AD zones, and they answer | One node points at a public resolver or a retired DC; Event 1258 names an unreachable server |
| 5. Zone | The zone that matches the primary DNS suffix exists, is AD-integrated, and accepts secure dynamic updates | Event 1256 or 1578; a zone set to None; the name registered in the wrong zone |
| 6. Record owner | Either no record exists, or the existing record grants the cluster's identity rights to update it | Event 1257, 1259, or 1580 after a rebuild, a hand-made record, or a DHCP registration |
| 7. Computer object | The CNO (and the role's VCO) exists, is enabled, is where the cluster expects it, and its password matches | "Logon failure: unknown user name or bad password."; Events 1193, 1194, 1206, 1207; a disabled CNO |
| 8. Time and Kerberos | Nodes, DNS servers, and DCs agree on time, and the identity can get a ticket | "DNS bad key", "DNS signature failed to verify.", or "DNS signature validity expired." |
| 9. Change | One link fixed, then the name re-registered | Records deleted, zone loosened, and Repair run in one go |
| 10. Proof | Every DNS server returns the right address, StatusDNS is 0, and a failover registers cleanly |
It works from one DC's DNS but not another's; the event returns on the next move |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Which name | The cluster's own name (core resource "Cluster Name", backed by the CNO) or a role's client access point (a file server, SQL Server instance, or other role, backed by a VCO). Different computer objects, possibly different record owners (Steps 6 and 7) |
| Which events, with their full text | 1195 or 1196 with the reason or code; 1257, 1256, 1258, 1259, 1260, 1261, 1262, 1578, 1579, or 1580; 1069 or 1205 if the resource or role failed outright (Step 2) |
| Which node owned the role | The owner node does the registration, so the node in the event matters more than the node you're signed in to (Steps 3 and 4) |
| Is the name online? | Online with a warning means clients may still reach the old record; failed means the role is down. That sets your urgency, not your fix |
| What resolves today | The address each DNS server returns for the name, and the address the cluster expects (Steps 3 and 10) |
| Since when, and what changed | A cluster rebuild with the same name, a node added or rebuilt, a new DC or a retired one, adapter or IP changes, DNS zone changes, scavenging enabled, a record created or deleted by hand, a computer object moved or disabled, a restore |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| 1196 with the reason "DNS bad key." | The secure update's signature or key was rejected; often a non-AD DNS server in the node's list, a record the identity can't update, or a Kerberos or time problem | Steps 4, 6, and 8 |
| 1196 "DNS operation refused." | The server refused the update: the zone doesn't take dynamic updates from this client, or the record's ACL blocks it | Steps 5 and 6 |
| 1195 with an error code | The same failure reported as a number; look the number up (9017 is DNS bad key) | Step 2 |
| 1257 "access to update the secure DNS Zone was denied" | Microsoft's guidance: "Ensure that cluster name object (CNO) is granted permissions to the Secure DNS Zone." | Steps 6 and 7 |
| 1580 "due to an existing record with this name" | Microsoft's text: "the cluster identity does not have the sufficient privileges to update that record" | Step 6 |
| 1256 or 1578 | The zone doesn't accept dynamic updates, or the node's adapter is pointed at a server that doesn't | Steps 4 and 5 |
| 1258 "a DNS server could not be reached" | The event names the server; the node can't reach it, or it's a server you retired | Step 4 |
| 1259 "failed clean up the existing records" | Old records under the name can't be removed by the cluster's identity | Step 6 |
| 1262 PTR failed | Reverse lookup zone missing or not dynamic, with PTR publishing turned on | Steps 3 and 5 |
| 1193, 1194, 1206, 1207, or "Logon failure: unknown user name or bad password." | A computer object problem, not a DNS one | Step 7 |
| Registers on one node, fails on another | That node's adapters, suffix, or DNS server list differ | Step 4 |
| Started right after a cluster rebuild with the same name | The records belong to the old CNO; Microsoft notes "The issue persists even if you destroy the cluster and then rebuild it." | Steps 6 and 7 |
Step 2: Read the event and its reason (read-only)
Read the events from every node, not just the one you're on. Microsoft's own Event Viewer path is the System log filtered to the FailoverClustering source; this is the same read in PowerShell:
# Read-only: network name DNS events from the System log on every node
$ids = 1069, 1195, 1196, 1205, 1256, 1257, 1258, 1259, 1260, 1261, 1262, 1578, 1579, 1580
foreach ($n in (Get-ClusterNode).Name) {
Get-WinEvent -ComputerName $n -MaxEvents 50 -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-FailoverClustering'
Id = $ids
} -ErrorAction SilentlyContinue |
Select-Object @{n='Node';e={$n}}, TimeCreated, Id, Message
}
Then match the text against Microsoft's failover clustering event list:
| Event | Microsoft's message (excerpt) | What to read next (our reading) |
|---|---|---|
| 1195 | "failed registration of one or more associated DNS name(s). The error code was '%2'." | Look up the code (table below) |
| 1196 | "failed registration of one or more associated DNS name(s) for the following reason: %2." | The reason is the DNS error text |
| 1256 | "because the corresponding DNS Zone does not accept dynamic updates." | Zone settings (Step 5) |
| 1257 | "because the access to update the secure DNS Zone was denied." | Record owner and CNO rights (Steps 6 and 7) |
| 1258 | "because the a DNS server could not be reached." (sic) | The DNS server named in the event (Step 4) |
| 1259 | "because the cluster service failed clean up the existing records corresponding to the network name." | Old records and their owner (Step 6) |
| 1260 and 1261 | "Cluster network name resource failed to modify the DNS registration." | The error code or reason in the event |
| 1262 | "failed to publish the PTR record in the DNS reverse lookup zone." | Reverse zone and PublishPTRRecords (Steps 3 and 5) |
| 1578 | "The DNS server may not be configured to accept dynamic updates." | Zone settings and the adapter's server list (Steps 4 and 5) |
| 1579 | "failed to update the DNS record for name '%2' over adapter '%4'." | Record owner (Step 6) |
| 1580 | "This was due to an existing record with this name and the cluster identity does not have the sufficient privileges to update that record." | Record owner (Step 6) |
Two text details matter when you search: Microsoft's 1256 and 1257 text says "associated DNS names(s)", and 1258 says "because the a DNS server could not be reached." Copy the event text as it is rather than retyping it.
The reasons and codes come from the Win32 DNS error list. The ones that show up most in these events:
| Code | Name | Microsoft's text | Usually points at (our reading) |
|---|---|---|---|
| 9017 (0x2339) | DNS_ERROR_RCODE_BADKEY | "DNS bad key." | The secure update itself: wrong server, record ACL, Kerberos, or time (Steps 4, 6, and 8) |
| 9016 (0x2338) | DNS_ERROR_RCODE_BADSIG | "DNS signature failed to verify." | Kerberos or time (Step 8) |
| 9018 (0x233A) | DNS_ERROR_RCODE_BADTIME | "DNS signature validity expired." | Clock skew (Step 8) |
| 9005 (0x232D) | DNS_ERROR_RCODE_REFUSED | "DNS operation refused." | Zone dynamic update setting or record ACL (Steps 5 and 6) |
| 9002 (0x232A) | DNS_ERROR_RCODE_SERVER_FAILURE | "DNS server failure." | The DNS server itself, or its AD-integrated zone not loading |
| 9009 (0x2331) | DNS_ERROR_RCODE_NOTAUTH | "DNS server not authoritative for zone." | The node asked a server that doesn't host the zone (Step 4) |
| 9010 (0x2332) | DNS_ERROR_RCODE_NOTZONE | "DNS name in update or prereq is not in zone." | Wrong zone for the name's suffix (Step 5) |
Microsoft's older 1196 troubleshooting page also says to "Check the system event log for Netlogon or DNS events that occurred near the time of the failover cluster event." Those are usually the same root cause seen from the node's own registration.
Step 3: Read what the name resource reports (read-only)
Find every network name, its state, and the node that owns it. The core cluster name lives in the group Microsoft's tools call Cluster Core Resources; roles carry their own:
# Read-only: every Network Name resource, its role, state, and owner node
Get-ClusterResource |
Where-Object { $_.ResourceType.Name -eq 'Network Name' } |
Select-Object Name, OwnerGroup, State, OwnerNode
# The IP address resources each name depends on (an OR list in multi-subnet clusters)
Get-ClusterResourceDependency -Resource 'Cluster Name'
Get-ClusterResourceDependency -Resource 'FS01'
Then read the private parameters that drive DNS registration. Get-ClusterParameter is Microsoft's tool for this: used with a Network Name resource, "you can obtain DNS-related information about the resource."
# Read-only: the DNS-related parameters of one network name
Get-ClusterResource -Name 'Cluster Name' |
Get-ClusterParameter -Name DnsName, HostRecordTTL, RegisterAllProvidersIP, PublishPTRRecords, StatusDNS, LastDNSUpdateTime, CreatingDC
# The last DNS update time is a FILETIME; this turns it into a local date and time
$p = Get-ClusterResource -Name 'Cluster Name' | Get-ClusterParameter -Name LastDNSUpdateTime
[DateTime]::FromFileTime([int64]$p.Value)
Read the values against Microsoft's definitions:
| Parameter | Microsoft's definition | What to look for (our reading unless noted) |
|---|---|---|
| DnsName | "The full DNS label associated with the Netname resource." | The label you expect to see in DNS; the blog adds "It cannot be more than 63 characters in length." |
| StatusDNS | "The returned status code from the last DNS operation that the NetName resource performed." | 0 means the last operation succeeded; 9017 is DNS bad key, 9005 is refused (Step 2's table) |
| LastDNSUpdateTime | "The Last time, in 100 nanosecond units, recorded by the Netname registered DNS." | A date from before the problem started means nothing has registered since |
| HostRecordTTL | "Time To Live (TTL) in seconds to be set for the resource records published for the cluster name." | Default 1200; a long TTL explains clients that keep the old address after a fix |
| RegisterAllProvidersIP | "Setting this private property to 1 registers the IP addresses of all the provider IP address resources, independent of the online status of any individual provider IP address resource." | Set to 1 in a multi-subnet cluster, you should see every subnet's address in DNS, not just the online one |
| PublishPTRRecords | "Determines if PTR resource records, apart from A or AAAA, are published for the Cluster Name." | 1 with no dynamic reverse zone explains Event 1262 |
| CreatingDC | Listed by Microsoft as a Network Name private property | The DC the computer object was created on; useful when replication is in doubt (Step 7) |
Also check the IP address resources the name depends on. Microsoft's dependency example shows the name coming online when "EITHER" provider address does, so a name can be online while one address is offline and never registered:
# Read-only: state and address of the IP resources behind the name
Get-ClusterResource |
Where-Object { $_.ResourceType.Name -eq 'IP Address' } |
ForEach-Object {
$a = $_ | Get-ClusterParameter -Name Address
[pscustomobject]@{ Resource = $_.Name; State = $_.State; Group = $_.OwnerGroup; Address = $a.Value }
}
| Finding | What it means (our reading unless noted) |
|---|---|
| StatusDNS 0 and LastDNSUpdateTime recent | The last attempt worked; the event is old, or another node or name is failing |
| StatusDNS non-zero on every name | A node-wide or zone-wide cause: DNS servers, zone settings, or time (Steps 4, 5, and 8) |
| StatusDNS non-zero on one name only | That name's record or computer object (Steps 6 and 7) |
| An IP address resource offline or failed | Fix the address first (network, subnet, or IP conflict); the name can't register an address that isn't online |
| Name online on one node, failing after a move | Read Step 4 on the node it fails on |
| Distributed Network Name (DNN) instead of Network Name | A different resource type with its own properties (Microsoft describes a DNN as "an access point used by clients to connect to a Scale-Out File Server."); read its parameters the same way |
Step 4: Which DNS servers does the owner node ask? (read-only)
Microsoft's 1196 text is a DNS client instruction: "Ensure that the network adapters associated with dependent IP address resources are configured with at least one accessible DNS server." Read the adapters on every node, because the owner node does the work:
# Read-only: DNS servers, registration settings, and suffix per adapter, on every node
foreach ($n in (Get-ClusterNode).Name) {
Invoke-Command -ComputerName $n -ScriptBlock {
$c = Get-DnsClient
Get-DnsClientServerAddress -AddressFamily IPv4 |
Where-Object { $_.ServerAddresses } |
ForEach-Object {
$i = $_.InterfaceIndex
$d = $c | Where-Object InterfaceIndex -eq $i
[pscustomobject]@{
Node = $env:COMPUTERNAME
Adapter = $_.InterfaceAlias
Servers = $_.ServerAddresses -join ', '
Register = $d.RegisterThisConnectionsAddress
UseSuffix = $d.UseSuffixWhenRegistering
Suffix = $d.ConnectionSpecificSuffix
}
}
}
}
| Finding | What it means (our reading unless noted) |
|---|---|
| Every node lists the same DNS servers, all of them DCs or DNS servers that host your AD zones | Good; move on to Step 5 |
| A node lists a public resolver, a firewall, or an ISP server, even second or third | A server that doesn't host your zone can't take a secure update for it; this is a common source of "DNS bad key" and refused updates. Use forwarders on your DNS servers instead (Windows DNS Server Not Resolving External Names) |
| A node lists a DC that's been retired or is down | Event 1258 names it; the node waits on it before it tries another |
| Nodes differ from each other | Registration succeeds on some owners and fails on others; that's the "works until it fails over" pattern |
| Register is False on the cluster-facing adapter | Microsoft's blog: "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." |
| A connection-specific suffix with UseSuffix True | The name also registers in that suffix's zone, so that zone has to accept the update too |
| Storage, live migration, or heartbeat adapters list DNS servers | Usually not the adapters behind the name's IP resources; leave them unless they carry the name's address (our reading) |
Then prove the node can reach and query each server it lists, by name and by the zone's SOA:
# Read-only: from the owner node, ask each listed DNS server about the zone and the name
$zone = 'contoso.com'
$name = 'CLUSTER1.contoso.com'
foreach ($s in '10.0.0.10', '10.0.0.11') {
Test-NetConnection -ComputerName $s -Port 53 |
Select-Object ComputerName, TcpTestSucceeded
Resolve-DnsName -Name $zone -Type SOA -Server $s -DnsOnly -ErrorAction SilentlyContinue |
Select-Object Name, PrimaryServer
Resolve-DnsName -Name $name -Type A -Server $s -DnsOnly -ErrorAction SilentlyContinue |
Select-Object Name, IPAddress, TTL
}
A server that can't return the zone's SOA isn't a server this node should be updating through (our reading). Microsoft's dynamic update article explains why the SOA matters: for a directory-integrated zone, "any DNS server that is loading the zone can respond and dynamically insert its own name as the primary server of the zone in the SOA query response."
Step 5: Does the zone accept the update? (read-only)
The name registers in a predictable zone. From Microsoft's failover clustering blog: "The registration for a cluster network name always happens in the zone corresponding to the Primary DNS Suffix of the host." Check the node's primary suffix, then the zone on each DNS server:
# Read-only: the primary DNS suffix of each node (the zone the name registers in)
foreach ($n in (Get-ClusterNode).Name) {
Invoke-Command -ComputerName $n -ScriptBlock {
[pscustomobject]@{
Node = $env:COMPUTERNAME
Domain = (Get-CimInstance -ClassName Win32_ComputerSystem).Domain
Suffix = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters').Domain
}
}
}
# Read-only: zone type, AD integration, and dynamic update setting on each DNS server
foreach ($s in 'DC01', 'DC02') {
Get-DnsServerZone -Name 'contoso.com' -ComputerName $s |
Select-Object @{n='Server';e={$s}}, ZoneName, ZoneType, IsDsIntegrated, DynamicUpdate, ReplicationScope
}
| Finding | What it means (our reading unless noted) |
|---|---|
| DynamicUpdate Secure, IsDsIntegrated True | The normal, safe setting; registration then depends on the record's ACL (Step 6) |
| DynamicUpdate None | Event 1256 or 1578. Microsoft's guidance: "Ensure that the DNS is configured as a Dynamic DNS zone. If the DNS server does not accept dynamic updates uncheck the 'Register this connection's' addresses in DNS' in the properties of the network adapter." Pick one on purpose: a dynamic zone, or static records you maintain |
| DynamicUpdate NonsecureAndSecure | Updates are accepted without security; registration should work, and anyone can overwrite the name. Not a setting to adopt as the fix (see the change-vs-avoid table) |
| Zone not AD-integrated | Microsoft: "The secure dynamic update functionality is supported only for Active Directory-integrated zones." |
| Zone missing on one DNS server | That server can't take the update; the node may be asking it (Step 4) |
| Primary suffix differs between nodes, or doesn't match the zone | The name registers in different zones depending on the owner node; fix the suffix, not the zone |
| A reverse zone is missing and PublishPTRRecords is 1 | Event 1262 only; the A record can still be fine |
If scavenging is on, read the record's timestamp too (Step 6). Microsoft's scavenging article: "Windows clients dynamically update DNS every 24 hours. All DDNS records are set to scavenge." A cluster name that can't refresh because of a 1257 can then age out and disappear, which turns a warning into an outage (DNS Scavenging Not Working covers the aging rules).
Step 6: Who owns the existing record? (read-only)
This is the step most 1257, 1259, 1579, and 1580 events end at. Microsoft's dynamic update article states the default policy: clients "try to overwrite a previously registered resource record, unless they are specifically blocked by update security." In a secure zone, the record's ACL is that security. Read the record first:
# Read-only: the record as each DNS server holds it (Timestamp empty or 0 = static)
foreach ($s in 'DC01', 'DC02') {
Get-DnsServerResourceRecord -ZoneName 'contoso.com' -Name 'CLUSTER1' -ComputerName $s -ErrorAction SilentlyContinue |
Select-Object @{n='Server';e={$s}}, HostName, RecordType, Timestamp, TimeToLive,
@{n='Data';e={$_.RecordData.IPv4Address}}
}
Then read its owner and ACL. In an AD-integrated zone the record is a dnsNode object; this reads it without changing anything:
# Read-only: owner and ACL entries of the record object (domain-wide replication scope shown)
$dom = (Get-ADDomain).DistinguishedName
$rec = Get-ADObject -Server DC01 -SearchBase "DC=DomainDnsZones,$dom" `
-LDAPFilter '(&(objectClass=dnsNode)(name=CLUSTER1))' -Properties nTSecurityDescriptor, whenCreated
$rec | Select-Object DistinguishedName, whenCreated
$rec.nTSecurityDescriptor.Owner
$rec.nTSecurityDescriptor.Access |
Where-Object { $_.IdentityReference -match 'CLUSTER1|Authenticated Users|Everyone|DnsUpdateProxy' } |
Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType
In DNS Manager, the same read is the record's Properties > Security tab (on older consoles, View > Advanced first). Read the results like this:
| Finding | What it means (our reading unless noted) |
|---|---|
| No record exists | The cluster should be able to create one; Microsoft's blog: "By default, all Authenticated Users have permissions to create a new record inside a secure zone." If it still fails, the cause is the zone, the server, or time (Steps 4, 5, and 8) |
| Owner is the CNO (or the role's computer object) and it has Full Control | Ownership is fine; look at Steps 7 and 8 |
| Owner is a user or an admin account, Timestamp empty | Somebody created a static record by hand; the cluster's identity has no rights on it. The blog: "if a record already exists, the security principal (in this case the cluster name identity) should have Full Control over the existing DNS record." |
| Owner is a SID that doesn't resolve | The identity that created it is gone: often the CNO of a cluster you destroyed and rebuilt with the same name (the new CNO is a new object with a new SID) |
| Owner is a DHCP server or the DnsUpdateProxy group | DHCP registered the address before the cluster did. Microsoft explains the general rule: "After the DHCP server becomes the owner of the client name, only that DHCP server can update the name." |
| The record exists in one DNS partition and the zone in another | A leftover copy from an old replication scope; read both partitions before you assume which one clients get |
| Record timestamp old, zone scavenging on | It's refreshing on time or it's about to be scavenged (Step 5) |
For a zone stored in the forest-wide partition, use DC=ForestDnsZones and the forest root in -SearchBase instead. For a role's name (FS01, a SQL Server instance), repeat with that name; Microsoft's 1580 text refers to "the cluster identity" and its record, so compare the record's owner with both the CNO and the role's own computer object rather than guessing which one should be there.
Step 7: Is the computer object behind the name healthy? (read-only)
The network name acts as a computer account in AD: the CNO for the cluster name, and a VCO for each role's client access point. Microsoft's description: "Through the CNO, virtual computer objects (VCOs) are automatically created when you set up clustered roles that use client access points." Read both:
# Read-only: the CNO and a VCO, as one DC sees them
Get-ADComputer -Identity 'CLUSTER1' -Server DC01 -Properties Enabled, DistinguishedName, whenCreated, PasswordLastSet, ObjectGUID |
Select-Object Name, Enabled, DistinguishedName, whenCreated, PasswordLastSet, ObjectGUID
Get-ADComputer -Identity 'FS01' -Server DC01 -Properties Enabled, DistinguishedName, PasswordLastSet |
Select-Object Name, Enabled, DistinguishedName, PasswordLastSet
# The GUID the name resource expects, to compare with the AD object above
Get-ClusterResource -Name 'Cluster Name' | Get-ClusterParameter -Name ObjectGUID
| Finding | What it means (our reading unless noted) |
|---|---|
| Enabled True, GUIDs match, PasswordLastSet recent | The object is healthy; the failure is DNS-side (Steps 4 to 6 and 8) |
| Enabled False | Microsoft's first resolution step for the rebuilt-cluster 1257 case is to "Verify that the CNO exists in Active Directory, and that it isn't disabled." A prestaged CNO is created disabled on purpose, but a running cluster's CNO shouldn't stay that way |
| Object not found | Deleted or moved to a container the cluster can't see; restore it from the AD Recycle Bin if it's there rather than creating a new one with the same name |
| GUIDs differ | The AD object with that name isn't the one the cluster created; often a rebuild or a hand-made replacement, and the DNS record ACL usually points at the old one (Step 6) |
| Event text "Logon failure: unknown user name or bad password." | Microsoft: "the password for the cluster name account no longer matches the corresponding password stored by the clustering software." Repair Active Directory Object is the documented fix (Step 9) |
| Events 1193 or 1194 for a role | The CNO couldn't create the VCO. Microsoft's checklist: the cluster identity "can create computer objects", "The quota for computer objects has not been reached.", and an existing object grants the cluster identity "'Full Control' permission to that computer object" |
| Events 1206 or 1207 | Microsoft: "The cluster identity '%5' may lack permissions required to update the object." |
| Events 1211 or 1212 | The node couldn't find a writable DC; Microsoft's guidance adds "Also ensure that the DNS server is running in order to resolve the name of the domain controller." |
The rights Microsoft documents for these objects:
| Object | Right | Where Microsoft says it |
|---|---|---|
| CNO on its OU or container | "Create Computer objects and Read all properties" | Troubleshoot issues with accounts used by failover clusters |
| CNO on each VCO | "Full control" | Same article; and Prestage cluster computer objects |
| CNO on the secure DNS zone (rebuilt-cluster 1257 case) | "the Create all child objects and Write all properties permissions" | Cluster role doesn't come online after you rebuild the cluster |
| Cluster identity on an existing DNS record | "Full Control over the existing DNS record" | DNS Registration with the Network Name Resource (failover clustering blog) |
| Default Computers container | "a cluster administrator can create up to 10 VCOs without any additional configuration" | Prestage cluster computer objects |
Step 8: Is time or Kerberos in the way? (read-only)
A secure update is signed with the identity's Kerberos credentials, so "DNS bad key", "DNS signature failed to verify.", and "DNS signature validity expired." can be identity or clock problems rather than DNS ones (our reading). Read time and tickets from the owner node:
# Read-only: time offset of each node against a DC, and the node's own secure channel
foreach ($n in (Get-ClusterNode).Name) {
Invoke-Command -ComputerName $n -ScriptBlock {
w32tm /stripchart /computer:DC01 /samples:3 /dataonly
w32tm /query /status
}
}
REM On the owner node, elevated: tickets held by the computer (SYSTEM) logon session
klist -li 0x3e7
| Finding | What it means (our reading unless noted) |
|---|---|
| Offsets of a few seconds | Not the cause |
| A node minutes off, or syncing from its host or a local clock | Fix time first; Windows Time Not Syncing With Domain Controller covers the w32tm and VM integration chain |
| Kerberos errors in the System log near the 1196 (for example, the target principal name is incorrect) | The DNS server's or DC's identity doesn't match its name; The Target Principal Name Is Incorrect covers that chain |
| The DNS server in the node's list is a non-Windows server for your AD zone | Secure updates may not be supported there at all; Microsoft's older 1196 page notes a hotfix for third-party BIND servers on Windows Server 2008 R2 |
| Time and Kerberos both clean | Go back to Steps 4 and 6; BADKEY is then most often the server or the record |
Step 9: Change one link, then re-register (a change)
Fix only what Steps 2 to 8 showed, then re-register the name and read the result before changing anything else.
The node's DNS server list (Step 4). Point every cluster-facing adapter at your AD DNS servers only, the same list on every node:
# A change, on the node that was wrong: replace its DNS server list on one adapter
Set-DnsClientServerAddress -InterfaceAlias 'Mgmt' -ServerAddresses '10.0.0.10', '10.0.0.11'
# Re-read it
Get-DnsClientServerAddress -InterfaceAlias 'Mgmt' -AddressFamily IPv4
The adapter's registration setting (Step 4). If the cluster-facing adapter had registration turned off and the zone is dynamic, turn it back on for that adapter (Set-DnsClient -InterfaceAlias 'Mgmt' -RegisterThisConnectionsAddress $true). If the zone is meant to be static, leave it off and maintain the records yourself, on purpose.
The zone's dynamic update setting (Step 5). If an AD-integrated zone was set to None by mistake, set it to secure only, not to nonsecure. Microsoft's -DynamicUpdate values are None, Secure, and NonsecureAndSecure:
# A change: AD-integrated zone back to secure dynamic updates only
Set-DnsServerPrimaryZone -Name 'contoso.com' -DynamicUpdate Secure -ComputerName DC01
The record's ACL (Step 6). For an existing record the cluster can't update, the narrow fix is the record, not the zone: in DNS Manager, open the record's Properties > Security, add the cluster's computer object (CLUSTER1$; enable Computers in Object Types), and give it Full control, as Microsoft's blog describes. For the rebuilt-cluster case, Microsoft's documented resolution is the zone-level grant: on the zone's Properties > Security, "Verify that the CNO has the Create all child objects and Write all properties permissions. If the permissions are missing, configure them."
A stale record you've decided to remove (Step 6). Only when its owner is gone or wrong and the cluster can't take it over. Microsoft's Remove-DnsServerResourceRecord deletes "all records that match RRtype and Name" unless you give -RecordData, so name the address:
# A change: remove one stale A record by its address, previewing first
Remove-DnsServerResourceRecord -ZoneName 'contoso.com' -RRType 'A' -Name 'CLUSTER1' -RecordData '10.0.0.50' -ComputerName DC01 -WhatIf
Remove-DnsServerResourceRecord -ZoneName 'contoso.com' -RRType 'A' -Name 'CLUSTER1' -RecordData '10.0.0.50' -ComputerName DC01
Clients that cached the old record keep it for its TTL, and the name doesn't resolve until the cluster re-registers, so do this in a window and re-register right away.
The computer object (Step 7). If the object is disabled and it's the running cluster's CNO, enable it (Enable-ADAccount -Identity 'CLUSTER1$'). For the password mismatch, use Microsoft's procedure in Failover Cluster Manager: expand Cluster Core Resources, under Cluster Name right-click the Name item and select Take Offline, then More Actions > Repair Active Directory Object. Microsoft notes that "Taking the cluster's Name resource offline shouldn't negatively impact other cluster groups, such as the SQL Server Failover Cluster Instance." Bring the name back online afterwards. Microsoft's account troubleshooting article also covers the CNO's rights on its container and on each VCO, and the computer account quota (ms-DS-MachineAccountQuota) when VCO creation fails.
Re-register the name. Use the online path first, then read the status:
# A change, without taking the name offline: re-register network names in DNS
Get-ClusterResource -Name 'Cluster Name' | Update-ClusterNetworkNameResource
Get-ClusterResource -Name 'FS01' | Update-ClusterNetworkNameResource
# Read the result
Get-ClusterResource -Name 'Cluster Name' | Get-ClusterParameter -Name StatusDNS, LastDNSUpdateTime
If it still fails, take that one name offline and back online in a window (Stop-ClusterResource -Name 'FS01' then Start-ClusterResource -Name 'FS01'). Microsoft's Stop-ClusterResource example notes: "Before taking the resource offline, it takes offline any dependent resources." For a role's name, that means the role's clients lose it, so read the dependency report first. Taking a name offline doesn't clean DNS either; the blog: "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."
When the event is gone, collect the logs anyway if it took more than one change; Microsoft's data collection step for this issue is Get-ClusterLog -UseLocalTime -Destination with a folder:
# Read-only: cluster log from every node for the last 30 minutes, local time, copied here
Get-ClusterLog -UseLocalTime -TimeSpan 30 -Destination C:\Temp\ClusterLogs
Select-String -Path C:\Temp\ClusterLogs\*.log -Pattern 'DNS' | Select-Object -Last 40
Step 10: Prove every DNS server answers with the right address (read-only)
Ask every DNS server that clients use, not just the one the node used, and then make the cluster register from another node:
# Read-only: what each DNS server returns for each network name
$names = 'CLUSTER1.contoso.com', 'FS01.contoso.com'
$servers = '10.0.0.10', '10.0.0.11', '10.1.0.10'
foreach ($s in $servers) {
foreach ($nm in $names) {
Resolve-DnsName -Name $nm -Type A -Server $s -DnsOnly -ErrorAction SilentlyContinue |
Select-Object @{n='Server';e={$s}}, Name, IPAddress, TTL
}
}
# Read-only: the cluster's own view after the change
Get-ClusterResource | Where-Object { $_.ResourceType.Name -eq 'Network Name' } | ForEach-Object {
$st = $_ | Get-ClusterParameter -Name StatusDNS
[pscustomobject]@{ Name = $_.Name; State = $_.State; Owner = $_.OwnerNode; StatusDNS = $st.Value }
}
Then, in a window, move the role to each other node and read the events and StatusDNS again. Microsoft's own resolution for the rebuild case ends the same way: "To test the cluster, perform a manual failover." and "Review the event logs to verify that DNS registration succeeds and doesn't generate permission errors."
# A deliberate move (the role restarts on the other node), then the same reads
Move-ClusterGroup -Name 'FS01' -Node HVN01
Get-ClusterResource -Name 'FS01' | Get-ClusterParameter -Name StatusDNS, LastDNSUpdateTime
Pass criteria (our reading): every DNS server returns the expected addresses (all subnets if RegisterAllProvidersIP is 1); StatusDNS is 0 for every network name; LastDNSUpdateTime is after your change; no new 1195, 1196, 1257, 1258, 1259, 1578, 1579, or 1580 on any node after a move; the record's owner and ACL include the cluster's identity; and Test-Cluster -Include 'Network' (Microsoft lists Network among the validation test types) runs clean if you changed adapters.
Common false starts
| False start | Why it doesn't help (our reading unless noted) |
|---|---|
Running ipconfig /registerdns on the node |
Microsoft describes it as a way "to manually force an update of the client name registration in DNS." It's the node's own name, not the cluster's network names |
| Deleting every record for the name "to be safe" | Without -RecordData, removal deletes all records matching the name and type; clients lose the name until the cluster re-registers, and the cause (server, zone, or identity) is still there |
| Giving Authenticated Users or Everyone full control of the zone | Fixes the symptom by letting any account overwrite any record in the zone |
| Switching the zone to nonsecure updates | Same: every client can then overwrite the name, including the cluster's |
| Running Repair for a 1257 | Repair Active Directory Object is Microsoft's fix for the cluster name account's password; it doesn't change the record's ACL |
| Recreating the CNO by hand with the same name | A new object with a new SID; the old record ACL and the cluster's stored GUID still point at the old one |
| Creating a static A record so it resolves | Works until the next failover or address change, and the cluster's identity can't update it unless you grant it rights (Microsoft's 1196 page does say to recreate a deleted or scavenged record; if you do, give the cluster's identity Full Control on it) |
| Testing from the node you're signed in to | The owner node registers; test the node in the event |
| Reading one DC's DNS | Each DNS server answers from its own copy; replication may not have arrived yet |
| Lowering HostRecordTTL as the fix | Changes how fast clients notice a correct record; it doesn't make registration succeed |
| Clearing the client DNS cache and calling it fixed |
Clear-DnsClientCache changes what one client remembers, not what the server holds |
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| One node lists a public or retired DNS server | The same AD DNS servers on every node's cluster-facing adapters | Adding more DNS servers to the list until one works |
| Zone set to None by mistake | Secure only on the AD-integrated zone | NonsecureAndSecure as the fix |
| Hand-made or DHCP-owned record blocks the update | Full control for the cluster's computer object on that record | Full control for Authenticated Users or Everyone on the zone |
| Rebuilt cluster with the same name, Event 1257 | Microsoft's grant to the new CNO on the zone, or a record ACL that names the new CNO | Recreating the CNO by hand to match the old SID |
| Stale record whose owner is gone | Remove that record by its address in a window, then re-register at once | Removing every record for the name without -RecordData
|
| CNO disabled | Enable it, then read the object's location and rights | Creating a second object with the same name |
| "Logon failure: unknown user name or bad password." | Take the cluster Name offline and run Repair Active Directory Object | Repair as a fix for DNS ACL errors |
| Node clock off | Fix time on the node and its source first | Loosening DNS security to work around a Kerberos failure |
| Name registered but clients still get the old address | Wait out or lower HostRecordTTL on purpose, and flush the clients that matter | Deleting and recreating the record again |
FAQ
What does "Cluster network name resource failed registration of one or more associated DNS name(s)" mean?
The network name couldn't create or update its DNS records from the node that owns it. Event 1196 adds the DNS error as text after "for the following reason:", and Event 1195 gives it as a code. Read that reason, the name's StatusDNS, and the owner node's DNS server list before you change anything (Steps 2 to 4).
How do I fix Event 1196 "DNS bad key" on a failover cluster?
Check, in order: that every node's cluster-facing adapter lists only your AD DNS servers; that the zone is AD-integrated and set to secure updates; that the existing record grants the cluster's computer object rights to update it; and that the node's clock and Kerberos are healthy. Fix the one that's wrong, then run Update-ClusterNetworkNameResource and read StatusDNS again (Steps 4 to 9).
What permissions does the cluster name object need on DNS for Event 1257?
Microsoft's guidance in the event is "Ensure that cluster name object (CNO) is granted permissions to the Secure DNS Zone." For a rebuilt cluster, its resolution is the zone-level "Create all child objects and Write all properties" for the CNO; for one existing record, the narrower fix is Full control for the cluster's identity on that record (Steps 6 and 9).
Does Repair Active Directory Object fix DNS registration?
Not by itself. Microsoft documents Repair for the case where "the password for the cluster name account no longer matches the corresponding password stored by the clustering software." It's greyed out until the cluster Name resource is offline. A 1257 caused by a record ACL needs the ACL fixed (Steps 7 and 9).
How do I re-register a cluster name in DNS without downtime?
Run Get-ClusterResource -Name 'Cluster Name' | Update-ClusterNetworkNameResource (or the role's name), which Microsoft says works "in a way that doesn't interrupt cluster availability." Then read StatusDNS and LastDNSUpdateTime, and ask every DNS server for the name (Steps 9 and 10).
Related posts
- DNS Scavenging Not Working (when the cluster name's record was aged out and deleted)
- Windows DNS Server Not Resolving External Names (when nodes list a public resolver because the forwarders were wrong)
- The Target Principal Name Is Incorrect (when the secure update fails on Kerberos between the node and the DNS server)
- Windows Time Not Syncing With Domain Controller (when "DNS bad key" or "signature validity expired" comes from clock skew)
Free checklist
Giving the whole zone to Authenticated Users, or switching it to nonsecure updates, before anyone read which record and which identity failed, is a change made everywhere at once. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=cluster-network-name-failed-registration
Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 and 10 are read-only checks: Get-WinEvent, Get-ClusterNode, Get-ClusterResource, Get-ClusterParameter, Get-ClusterResourceDependency, Get-DnsClient, Get-DnsClientServerAddress, Test-NetConnection, Resolve-DnsName, Get-DnsServerZone, Get-DnsServerResourceRecord, Get-ADObject, Get-ADComputer, w32tm /stripchart and /query /status, klist, and Get-ClusterLog. Changing DNS server lists or adapter registration, zone dynamic update settings, record or zone permissions, removing records, enabling or repairing computer objects, re-registering or restarting network names, and moving roles are deliberate changes. Change one link at a time, prove it from every DNS server and every node, and check current Microsoft Learn for version-specific behavior.
Top comments (0)