Failover Cluster DNS error, event 1257 keeps coming back

James Edmonds 811

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

James Edmonds 811 Reputation points

2022-06-15T10:16:32.077+00:00

My ocurrence of this issue just started again this morning.
I am able to resolve by taking the clustered role name resource offline and onlining it again.

What I have noticed, is that for a clustered role on another cluster, the permissions on the DNS entry for the role name resource lists the cluster name resource as having permissions.
On the one that was having issues this morning, it shows the role name resource as having permissions on itself, rather than the cluster name resource.

Should, when onlining the role name resource,, the cluster name object be what is given permissions on the DNS entry, rather than the role name object?

Banging my head against a brick wall here and started to get a bit frustrated.

Cheers
James
Jack Dobiash 6 Reputation points

2022-06-15T17:54:43.587+00:00

Hey James, I checked my cluster objects and at least in our version (Server 2016), the actual Cluster itself 'owns' and updates the DNS objects on itself and on any roles that it is hosting. If you check the 'Advanced' security area of the DNS record, it should show you who owns it as well. We haven't had any issues with the individual roles themselves (so far), just the main CNO object is what isn't updating it's DNS record.

I did notice that the pwdLastSet timestamp of my CNO is different than the individual roles (although they are within a day or so of each other), meaning they don't all get updated at exactly the same time. Did the password on that role object recently get updated? Just curious if your issue is similar to mine.

Lastly, if you check the Diagnostic Failover Cluster event logs, you might be able to see something that occurs at the time when the DNS renewal is attempting. Those logs are pretty bloated, however, so it can be a bit of a pain to find stuff (try and filter out 'information' events), and usually they rollover pretty quickly (if the log size isn't increased) so you almost need to find it while the event is occurring.

Hope this helps!
James Edmonds 811 Reputation points

2022-06-16T10:59:24.99+00:00

Hi Jack,

I'm interested in what roles you are hosting?
I think my issue is that, for both my CNOs and my SQL role DNS name resource, the owners of the DNS objects are the cluster name objects themselves.
In the case of my problematic file server role, the owner is the role itself.

See below. Top two entries are the CNOs. Bottom left is the problematic file server role, and bottom right is SQL role:

It seems as though when the file server role DNS name resource is brought online, it is not setting ownership of the DNS entry correctly?

I am not sure if my password reset times suggest my issue is the same as yours?

Cheers
James
Jack Dobiash 6 Reputation points

2022-06-28T00:24:44.247+00:00

So aside from Hyper-V, the two 'Roles' we have on our non-HyperV cluster is DHCP and the 'Generic' one running Certificate Services. No issues with either of those. Our main CNO Name issue came back today on our Hyper-V cluster, right on schedule (22 days between password changes).

I just got done doing some more testing and the results are 'interesting' to say the least. Instead of just stopping and starting the 'Name' role to fix it again, I decided to actually delete the DNS record right before it was about to attempt to renew it. To my surprise, it registered the new record in DNS, but really to my surprise, the 'owner' of the record was no longer the CNO, but one of the 'Roles' on the Cluster, the Hyper-V Replica Role, to be precise. Keep in mind this is the DNS record for the actual CNO, not the role, but yet it used the Replica Role account to register the DNS name. The Replica role has it's own DNS record, which is owned by the main CNO, and it's been updating fine this whole time.

As another test, I've now 'stop/started' the 'Name' role on the cluster, and I'm going to see if, when it updates the DNS record in ~24 hours, it fails again. I suspect it will, as then it will be trying to use the proper Cluster account name again and it won't have access anymore.

It'll be interesting to see what happens when I try this on my other non-Hyper-V cluster, once it starts having the problem (which should be here in the next day or so).
James Edmonds 811 Reputation points

2022-06-28T09:04:04.817+00:00

I think this too is what we are seeing on one of our clusters.
The owner of the DNS record after deleting it manually, and having the cluster recreate it by bringing it offline and online, is one of the roles rather than the cluster itself.

If you're environment then behaves like mine, it'll be fine for ages, then at some yet to be determined interval, it will start triggering event ID 1257, saying it cannot be updated.

I'm still monitoring ours, but due to a number of power outages recently, our clusters have been fully stopped a number of times, so I have no idea what the real interval between event ID 1257s is at the moment.

Let me know how yours goes.

Cheers
James
Jack Dobiash 6 Reputation points

2022-06-30T02:03:21.46+00:00

So our other Cluster was due for the problem as well, so I waited until it started throwing out event ID 1257 again, then just deleted the DNS record for that clusters main CNO. Similar to before, once it tried again (it tries every 15 mins once it fails) it registered in DNS, but now the "DHCP" role owns it. It's almost like I'm having the exact opposite issue as you, where my main CNO DNS object is now being 'owned' by the roles it maintains, rather than by itself. So far, no errors have ever happened when attempting to register the roles DNS, but it might be that I'm not waiting long enough after the main CNO quits being able to update itself.

If I delete the DNS record, and then stop/start the 'Name' role on the cluster itself, it re-registers the DNS record under it's own name properly. The next time the password is updated is when it switches to one of the roles.

I'm still leaning towards the thought I had when I originally posted, which was that my cluster basically 'forgets' how to login under it's own name after it changes the password on the CNO, but somehow it's falling over to using one of the roles credentials. I suppose I can just add both the roles and the main CNO object as being able to write to the DNS record. This will probably make it work, however I would still consider this a 'workaround' to a bug that was introduced within the last 6 months or so.
James Edmonds 811 Reputation points

2022-07-01T18:46:31.437+00:00

Yes, to me it feels like a bug, as the cluster CNO should take ownership of its own DNS record.
I can see no logical reason it wouldn't do that, unless there was a bug that meant it didn't try, or skipped to using the role CNO if the cluster is not able to for some reason.

Very odd.

I cannot raise with Microsoft sadly, as we have no premier support, but perhaps if enough people notice the issue and post here, they may look into it.

Cheers
James

15 answers

AussieCraig 1 Reputation point

2022-08-22T22:40:44.987+00:00

Some more info in case it helps with the diagnosis...
We have a Windows Server 2019 Hyper-V Failover Cluster and have had this error occur 3 times since the beginning of June. May be a coincidental, but in each case there has been a "Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.373.791.0)" installed in the preceding half hour.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
Schultz Thomas 1 Reputation point

2022-08-31T08:18:22.577+00:00

We see this also on all of our 2019 clusters. The DNS VCO security only includes the correct VCO with Read/Write but the needed computer cluster object with Full Control is missing.
We had troubles in the past with the CU10-2022(I think it was this CU). After this update VCO DNS security include a random VCO of the cluster, but not the correct one, also the cluster computer object was missing.
https://support.microsoft.com/en-us/topic/november-22-2021-kb5007266-os-build-17763-2330-preview-c9ba0c4c-c8b7-409a-8fac-a76ffae8f94f

After the installation of the next CU, VCO DNS security includes the correct VCO object but still not the the cluster computer object.

So for me it looks like, that the cluster nodes doesn´t register the DNS entry with correct security settings because the cluster computer object with "Full Controll" is still missing.
This behaviopir didn´t change with newer monthly CU updates.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
Anonymous

2022-09-16T15:02:04.193+00:00

I have seen that posted on the internet as a fix, but checking the box "Allow any authenticate user to update DNS record with the same owner name" what does that mean exactly?

What does any authenticated user with the same owner name mean from a security perspective?

Would it be better to change the DNS records to static and uncheck the box on the network connection on each server to "register server in dns..." option under the advanced TCP/IP > DNS settings or are there issues if I do this?

We have several windows clusters and some of the DNS entries are not being updated and are being scavenged by DNS.

Is there any official microsoft guidance on this issue?

What was your "fix"?
Please sign in to rate this answer.
James Edmonds 811 Reputation points

2022-09-16T15:52:22.53+00:00

I don't currently have a fix, other than to manually bring the DNS name offline and online again in order to recreate the DNS object.
We are still awaiting an update from Microsoft on this issue.

Anonymous

2022-09-16T16:56:12.12+00:00

Thanks, so you did not make any changes you just take the cluster offline?

Jack Dobiash 6 Reputation points

2022-09-16T23:04:30.767+00:00

There are basically two ways to deal with this situation that I've found:

1.) Restart the 'Name' resource role in the cluster. Keep in mind this is ONLY that 'Name' role, not the entire cluster itself. The Name role can be found by highlighting the root of the cluster in the Failover Cluster Manager, then down under 'Cluster Core Resources', right-click the 'Name: <YOUR CLUSTERNAME>' entry, then select 'Take Offline'. After it goes offline, right-click it again and select 'Bring Online'. This method will need to be done every time the issue occurs, it is not usually a permanent fix. The good news is that restarting the Name role is quick and won't likely result in any downtime, as your other resources will remain online.

2.) Add the AD Object of other roles you have in your cluster to be able to update the DNS record for your main cluster. For instance, in our Hyper-V cluster, we have the 'Hyper-V Replica Broker' role. If I add it's AD Object (VCO) as an entry onto our Clusters DNS record (and give it write access), it's then able to update it when the issue occurs. On our non-HyperV cluster we have two roles, so adding the AD objects for those two onto that Clusters DNS record make that work. This is more of a 'workaround' than a 'fix', as the underlying problem still exists, this just keeps the errors from happening in your logs and also keeps your DNS record updated.

Hope this helps!
Sign in to comment
James Edmonds 811 Reputation points

2022-10-25T08:46:53.267+00:00

I can't recall who had the ticket opened with Microsoft on this issue, but have they come back to advise on any ETA for a fix on this?

The manual changes to DNS records and security settings is a workaround, and the manual intervention of stopping and starting the name is a nuisance.
It would be good if they can get a permanent fix released to solve this fully.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
James Edmonds 811 Reputation points

2022-11-22T13:28:29.04+00:00

Has anyone heard back from Microsoft to confirm this is also a known issue in 2022, and if they are working on a fix?

Many thanks
James
Please sign in to rate this answer.
Jarrod 0 Reputation points

2023-03-07T06:23:19.11+00:00

My organization is seeing the same issue we are intending to log a ticket with Microsoft Regarding this.
Sign in to comment

Share via

Failover Cluster DNS error, event 1257 keeps coming back

15 answers