71–80 of 148 posts
What could a TLA do with this if it had time to plan ahead?
Serve malicious updates from a locally controlled machine, for one. Lord knows about auth.
Wouldn't they have to break into my local machine first, plant an update service, and an update? That doesn't seem to scale well at all, and wouldn't it be easier to just break into the machine they want to 'update'?
Earlier quoted context omitted.
Do most DNS forwarders not block addresses that resolve to a local IP these days? I know dnsmasq does, and NextDNS too I think.
Why? Having local IPs on a public DNS is a legitimate use case.
An entry-level admin is now unemployed, just before the holidays.
I hope not. Failures are on a spectrum and this was unfortunate but probably not malicious. All things considered this should be a lesson learned. There should be more failsafe mechanisms in place so juniors can fail safely and learn from them. The absolute worst thing we can do is shame an individual so they don’t attempt to try new things in fear of ridicule.
And if not, whoever put the junior in that role is the person responsible for the problem.
$ dig microsoft.com. | grep EDE
; EDE: 15 (Blocked)
resolver.log:Dec 20 00:43:57 router dnsmasq[8172]: possible DNS-rebind attack detected: microsoft.comI'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?
* Copy/Paste * Copilot told me * Sabotage (internal or external)
Wait... Can DNS resolvers be configured so that RFC1918 is respected? I mean: I don't expect anything less from Microsoft than doing stuff like that and it cannot affect me for I nullroute microsoft.com from my unbound server ( unboud takes wildcard when nullrouting or NXDOMAINing crap domains like microsoft.com or meta.com etc., which is sweet). However I'd expect my trusty DNS resolver to also prevent me from anyon…
Unbound's "private-address" and "private-domain" directives control this.
Similarly, bind9 has "deny-answer-addresses" (with an "except-from" option so you can specify local domains that are allowed to use them):
https://bind9.readthedocs.io/en/v9.18.20/reference.html#cont...
Not sure about others.
for uninitiated (me), why is it bad?
Wait... Can DNS resolvers be configured so that RFC1918 is respected? I mean: I don't expect anything less from Microsoft than doing stuff like that and it cannot affect me for I nullroute microsoft.com from my unbound server ( unboud takes wildcard when nullrouting or NXDOMAINing crap domains like microsoft.com or meta.com etc., which is sweet). However I'd expect my trusty DNS resolver to also prevent me from anyon…
(See also the sibling comment about microsoft.com being IPv6 only as a result of a particular implementation of DNS rebinding protection: https://news.ycombinator.com/item?id=38704159)
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?
This is the kind of thing you look at and put up a few guardrails to prevent it happening again.
Through a series of connections I know a guy that knows a guy that works at Microsoft that was made aware and the changes have been reverted. Give 'er 30 minutes TTL ;)
192.168.1.1 is gone now, but all authoritative nameservers are still offering 192.168.1.0. Oops.
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.com