Cluster Network Name Resource Failed Registration (Event 1196, 1257): A Read-First DNS, CNO, and Record Triage

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 StatusDNS parameter, 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 1: Capture the symptom (read-only)

Write these on the ticket first:

Then branch on what you see:

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:

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:

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:

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 }
    }

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
                }
            }
    }
}

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
}

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:

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

The rights Microsoft documents for these 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

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

When a change is justified

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:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=cluster-network-name-failed-registration

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.