We have three DCs, all at HQ, all 2012 R2.
Recently we opened a new branch location, and set up some printers with static addresses.
There is no DC in the new location (or anywhere outside of HQ - we're going to fix that).
Someone decided to redo the static addresses in the zone for the printers, so we updated them in DNS.
And yet, each time we made the changes, we saw that the changes reverted, after roughly 15 minutes. That's seems to be a suspicious time span.
I checked replication between the DCs (adreplstatus, repamdin), and it's fine - no errors.
I also checked the zone on each of the DCs after the change, and all had the updated addresses.
I checked the properties for the zone, and it's set on each DC to to replicate to all DCs in the forest.
Each DC lists itself as primary server for the zone.
However, the serial numbers are different between the DCs for this zone:400469 - dc2
400746 - dc1 <<<<< address changes done on this DC
400469 - dc0 <<<<< holds all FSMO roles
I've looked at ADSIEdit following Ace Fekay's articles on duplicate and conflicting zones and don't see any "In Progress" artifacts or other evidence of problems, with one possible exception:
The folders indicated in the screencap are named the same, and seem to be duplicates of each other. I haven't tried to do a visual diff of the contents, but have briefly eyeballed them, and they look pretty similar.
Since I'm at a new position, and don't have my old DCs to look at, I can't compare them to what is normal. However, those folders are duplicated on all three DCs.
I've run out of ideas for things to look at. I'm at the point of turning on DNS auditing, but am hesitating on pulling the trigger on that until it's the last resort.
Anyone have thoughts on this?
A puzzlement - static addresses changing/reverting
- 231 Views
- Last Post 13 January 2020
It's the ForestDNSZones, per the screencap, unless you mean something else, and I misunderstand you.
BTW - I'll check on this on Monday when I get back to work.
I'll probably have more questions ten.
I’d also take a look at the replication metadata on the records in question in addition to this.
Yes, I probably didn't communicate clearly. The printers were set with static addresses, and the entries in DNS were also static.
Well, I wasn't there to verify it for myself WRT the printers, so I had to go by what the helpdesk staff on site said.
I have no idea why they decided to change the IP addresses on the printers, and then also change the entries in DNS. Makes no sense to me, since all of the printers were on the correct VLANs.
Regardless, today I gook another look, and guess what I found:
I think that deleting the CNF entries is my next move, correct?
Technically yes. Practically confirm that the WhenChanged on the CNF object is not actively updating otherwise it is still in use.
Obvious and think you have it covered but backup, backup, backup. I’d be tempted (depending on environment) to restore into a LAB and run the steps there before unleashing in production but I’m old and careful now days :)
As is typical in underfunded organizations, we only have a lab environment, what we do not have is a production environment (what Ed said).
I'll take precautions...