as of 1703035296:
ns1-39.azure-dns.com no longer has 192.168.1.0 for microsoft.com
1.1.1.1 still has 192.168.1.0 for microsoft.com
8.8.8.8 still has 192.168.1.0 for microsoft.com
76.76.2.0 no longer has 192.168.1.0 for microsoft.com
9.9.9.9 still has 192.168.1.0 for microsoft.com
208.67.222.222 still has 192.168.1.0 for microsoft.com
185.228.168.9 still has 192.168.1.0 for microsoft.com
76.76.19.19 still has 192.168.1.0 for microsoft.com
94.140.14.14 still has 192.168.1.0 for microsoft.comNope. This is still Microsoft's fault while non-auth servers update.
I wasn't attempting to address blame since I figured that was obvious enough.
If it’s that simple for a stray record to be included in the dns round robin it could have been bad if it was an external ip with a machine setup by a phisherman especially since control of a domain is all you need to get an ssl cert now.
Couple this with the fact that it’s Microsoft, one of the most relied on companies in our computer world, this is pretty darn horrible.
They use 1drv.ms as the domain in OneDrive emails, and sometimes it almost looks like the .ms ccTLD belongs to them - it very much doesn't, anyone can register a .ms domain.
windows.net being an Azure domain that third parties can have content under is fitting.
It sometimes looks like they want their users to be phished.
Microsoft is a smart company though, I really hope they can sort this out.
https://learn.microsoft.com/en-us/microsoft-365/enterprise/u...
https://learn.microsoft.com/en-us/azure/security/fundamental...
> it could have been bad if it was an external ip with a machine setup by a phisherman
I.e. one of the IPs for microsoft.com belongs to $phisher, which means they control (a subset of the traffic going to) the domain. They can't add CNAME records for certificate validation, but LetsEncrypt for example offers HTTP-based validation.
Not sure how Microsoft sets up their certificate pinning, it might not be quite that easy.
https://en.wikipedia.org/wiki/Self-enquiry_(Ramana_Maharshi)