Hacker News Reader

Comment by jedisct1 | Hacker News Reader

Ironically, lying DNS resolvers redirecting nonexistent domains to ads were also helpful in order to mitigate the attack.

View on HN

DNS being one of the most fragile aspects of the net, a lot of issues can be solving by a local DNS resolver that does a lot of caching and blocking

I recommend pi-hole if you have a Raspberry Pi laying around: https://github.com/pi-hole/pi-hole

Sure, and something like dnscrypt-proxy can do that, but in what is being discussed here, blocking the domain would do the opposite of what you are trying to achieve.

The ransomware prematurely quits if the domain resolves to an IP, and a webserver listens to that IP.

Remember that time when VeriSign did this (wildcarding) on a global basis for .com and .net in 2003, briefly causing outrage?

"As of a little while ago (it is around 7:45 PM US Eastern on Mon 15 Sep 2003 as I write this), VeriSign added a wildcard A record to the .COM and .NET TLD DNS zones. The IP address returned is 64.94.110.11, which reverses to sitefinder.verisign.com. What that means in plain English is that most mis-typed domain names that would formerly have resulted in a helpful error message now results in a VeriSign advertising opportunity. For example, if my domain name was 'somecompany.com,' and somebody typed 'soemcompany.com' by mistake, they would get VeriSign's advertising."

https://m.slashdot.org/story/38665

Even today, T-Mobile still does that – any domains that can not be resolved are redirected to their ads.

Verizon does it too, although they just show search results and don't show ads. It's possible to opt out, but it hasn't bothered me enough to do that yet.

But VeriSign is not an ISP -- they were the ones running the authoritative root name servers and doing this to literally everyone.

Adding this domain to various adblocker list might also have interesting effects.

Reply on news.ycombinator.com