Failover Cluster DNS error, event 1257 keeps coming back

Question

Hi,

I have two failover clusters created, for which I did NOT pre-create the DNS records for the cluster or role names.
The DNS records are created when the cluster/role is brought online.

On one of the clusters, I keep getting event ID 1257, where it fails to register or update the DNS entry for the role running on the cluster.
If I delete the existing record, and restart the role, it creates successfully.

I am trying to understand why, if the cluster creates the record, this error keeps coming back?
What can I do to prevent this from constantly complaining about this, when both cluster nodes have access to that DNS record?

Thanks
James

Answer 1

The silence from Microsoft on this is deafening. To think, an enterprise level feature, is basically broken, and has been broken for a while now. I just closed a ticket with Microsoft support regarding this issue and they were of no help at all. The tech did indicate that this is a known issue with Microsoft but could not give me an ETA on a fix/patch for this issue. Also, he refused to produce the 'internal' documentation from Microsoft regarding this 'Known Issue'. The real kicker here is that this issue can be resolved by offlining the cluster, running the Update-ClusterNetworkNameResource (which works sporadically) command via PowerShell, execute a repair on the cluster, and/or sometimes it self-heals. Because of this the Microsoft tech always has an out, as they are technically break/fix and if an issue isn't broken they refuse to help, and tell you to submit a root cause analysis ticket to Microsoft Premier support. My argument is that these issues are SYMPTOMS of the real issue. If Microsoft knows the reason/cause for this issue they need to provide information on what causes this issue, HOW TO FIX IT, and/or a patch or ETA on when a patch will be published to resolve this issue.

Answer 2

I logged a case with Microsoft last year and the issue was acknowledged and fixed in Nov 21 KB5007266: "Addresses an issue that prevents Failover Clustering from updating Domain Name Server (DNS) records".

The issue then reared its head in Feb 2022 but it is intermittent for us depending on which node in which site is rebooted in which order etc. (patching normally). I finally gave in and logged another call last month, and just today we closed it with the "workaround" being the only solution they can provide for now, because supposedly they have not heard of it before! I referred to this chat, that Nov 21 CU etc. but unfortunately both were brushed over with instead new focus efforts done to capture more logs and recreate/repair etc. :(

Anyway, the fix for us was to change each CNO account to Full Control on the respective CNO DNS records, and to do the same for any related VCO accounts. In some cases, we also did the same on the VCO records (added Full Control for the CNO and VCO objects themselves) which I am not entirely convinced if that was necessary or not.

As part of "archiving" the case, I asked Microsoft to update their official documentation to reflect this workaround is required to overcome Event 1257 intermittently nutting off when a node might be rebooted.

Answer 3

James,

I have the same problem which I have not been able to resolve it yet.

This is what I noticed. I think we cannot simply delete CNO object which Microsoft recommends, or re-create it manually and grant it appropriate permissions (aka “Allow any authenticated user to update DNS record with the same owner name”).

On day 1, after manually creates it, the error didn't repeat but actually it didn't go away.
On day 7, the error 1257 ID of DNS came back.

The action above only creates the DNS record as STATIC (as opposed to Dynamic) with date/time stamp of last update by the virtual cluster server.

On another set of cluster servers (different DNS server, different domain), I noticed this CNO is a dynamically created name. Not static.

I wonder, how do we create this CNO object DNS name dynamically in the first place?

Answer 4

Hey all, we are also experiencing this on two of our clusters. I'm pretty sure it's a bug that was introduced by a patch sometime near the start of the year. We have a 3rd cluster which has not had the the issue, but it hasn't been updated in a while. We are running Server 2016 Clusters. I know pretty much exactly WHAT the problem is, but not how to fix it. The issue occurs every time the CNO password gets updated, which occurs around every 21 days (at least on our system). Once the password has been updated by the 'core' node, it then somehow 'forgets' what that new password is, at least when trying to update the DNS registration. The underlaying cluster event logs even indicate that it's basically failing to login to the DNS server when attempting to update the DNS record. If we just move the core resources from one node to another (and even back to the first node), things start working again, until the next time it updates the password on the CNO. The other option is to take the 'Name' resource offline and bring it back online, that also fixes it until the next password change.

If you want to see when the last time your CNO password was updated, check the Attributes of the actual Cluster Object in AD and look for 'pwdLastSet'. In our case, it's been like clockwork each time the password is updated on both clusters. Within 24 hours of the update it starts to complain again (since it updates DNS once a day).

I'm hoping may someone else can confirm they are in the same situation? Thanks!

Answer 5

Following as well