I'm trying to figure out how this could have happened, but I control so few IP addresses that many of my DNS entries are manually assigned. And you'd have to be incompetent if you have access to set DNS records and you set them to RFC 1918 addresses.
Anyone have any theories on how this could happen?
"It's only those who do nothing that make no mistakes, I suppose."
Now the persons that did it have some proof that they did something.
They will surely put some check in place because there should be another adage somewhere that says that you only learn to use the handrails after you fell in the stairs.
Certainly just some automation bug, perhaps a few things strung together, like a dev environment setup that leaked into production. A human in the loop making a mistake probably as well.
This is the kind of thing you look at and put up a few guardrails to prevent it happening again.
My guess is that someone at MS was testing Windows Updates or other changes from a local source. They also had some other DNS updates in their config they were testing. They took all of their config and pushed it out, when they should only have taken the other changes.
I hope that's not their workflow, but few people I've ever worked with have know how to create operating procedures that had half a chance of succeeding, usually it's based on "oh, don't worry, i would never do that"
>> And you'd have to be incompetent if you have access to set DNS records and you set them to RFC 1918 addresses.
Clearly the following is not in play for a root domain (Microsoft.com) but assigning a DNS entry to a class C address does have a purpose.
If you have an intranet server, giving it a DNS name allows for HTTPS serving, with an automatic, CA signed, certificate. (Using say LE with DNS challenge.)
I provide this simply as an example of how this might come about.
Anyone have any theories on how this could happen?