Tell HN: Microsoft.com added 192.168.1.1 to their DNS record
A misconfiguration briefly added private IP addresses (192.168.1.0/1) to the public DNS records for microsoft.com, meaning some users’ requests could resolve to their own home routers or local devices instead of Microsoft’s servers. Commenters explore the operational impact (timeouts, partial traffic loss, IPv6-only fallbacks), the security implications around DNS rebinding and certificate issuance, and how such an error might slip through change control at a large company. The incident also prompts broader reflections on DNS safety mechanisms, resolver-side protections against private address responses, and organizational guardrails to prevent similar mistakes.
What Happened
microsoft.combriefly had A records pointing to192.168.1.1and192.168.1.0, both private RFC1918 addresses.- Many users confirmed seeing these records via DNS lookups; one address disappeared first, the other lingered.
- The erroneous records were later removed from the authoritative nameservers, but public resolvers took time to flush their caches.
Immediate Effects & User Impact
- With 2 of 7 A records being private IPs, some clients randomly resolved
microsoft.comto local devices (often home routers or printers). - Symptoms included timeouts, connection failures, or opening a router admin page instead of Microsoft’s site.
- Some DNS setups (e.g., with DNS rebinding protection) blocked the responses, effectively making
microsoft.comIPv6-only or unreachable on those networks.
Security Concerns & Threat Models
- Several comments stressed that this is primarily a risk for Microsoft, not for end users’ networks.
- Potential risks discussed:
- If a malicious actor had controlled a public IP instead of private, they might have intercepted some traffic or attempted phishing.
- Possibility of using HTTP-based domain validation to get certificates, though this would require significant control and correct traffic routing.
- Others pointed out protections: HTTPS, signed updates, and DNS servers that reject private IPs in public answers as DNS-rebinding defenses.
- Some noted that misuse of
microsoft.comin this way could have been more dangerous if carefully planned by an attacker or state actor.
How Could This Happen? (Speculation Within Thread)
- Theories included: copy/paste error, automation or IaC bugs, dev/test configs leaking into production, or general ClickOps/process failures.
- Some doubted that entry-level staff could change such a critical zone, suggesting a more complex pipeline or review miss.
Process, Culture, and Lessons
- Calls for better guardrails: validation to block RFC1918 in major public zones, dual-control reviews, and automated checks.
- Mixed reactions: some see it as a harmless but embarrassing mistake; others view it as a serious process failure for a core internet dependency.