Document reasoning to block DNS to 127.0.0.1

I've debated that reasoning in the security field and it just goes round-and-round in circles. There are legit cases to avoid this but less about security and more about scanning tools that poorly detect attempts to the loop-back as DNS rebinding attacks vs. an actual DNS rebinding attack which requires malicious code. So avoiding this can avoid some false positives from 3rd party scanners and having to get into silly arguments with people. There are some other obscure edge cases but they delve more into hypothetical scenarios and people can never seem to show a real world implementation of their theoretical attack. Besides, there is nothing stopping anyone from pointing any domain to 127.0.0.1 on their recursive servers or via /etc/hosts so if this is a risk then somebody is doing something very wrong.

Funny story though, I used to park wildcard sub-domains on 127.0.0.1 just to keep the bots off the load balancers and a customer said that we were running a vulnerable version of PHP. I said we had no installations of PHP anywhere in production. Turned out they were scanning one of my parked wildcard sub-domains and effectively were scanning their own laptop which had some old PHP web app running on it. That also told me they were also not validating certs.

> if you're developing software you should probably be running without any addons like uBlock enabled to prevent surprises in production for your non-uBlock users.

It seems to me there's a higher risk that uBlock blocks something and breaks something than uBlock making something work that wouldn't for people not having it. I once had a filter block something called /share/ or share.js, fortunately I noticed during the development. I definitely prefer having it enabled while developing.

> Besides that, you can't get HTTPS for these domains (without the mess of a custom CA and even then you'll run into CT issues)

Indeed. I recently had to do this and found mkcert [1] which makes it very easy to do. But it's overkill for most situations.

[1] https://github.com/FiloSottile/mkcert

Not a fan of EasyPrivacy. It seems to be run by trigger happy people with pretty limited understanding of the web.

They once blocked workers.dev (Cloudflare Workers) wholesale[1], resulting in a huge flood of issue reports for a few FOSS services of mine. Guess they've never heard of public suffixes.

This one appears to be someone reading about DNS rebinding attack somewhere, then pulling the trigger without understanding it. Or maybe I even overestimated them, DNS rebinding only came up as a justification very deep into the discussion.

To make matters worse, clients using these block lists have update frequencies all over the place, so you can never be sure when your stuff gets unborked for all your users even after they revert changes like this.

[1] https://github.com/easylist/easylist/commit/e4b0216

> you can't get HTTPS for these domains

What are you talking about? Certificate insurance and DNS A/AAAA records are entirely decoupled. Use the ACME dns-01 challenge to get a cert for domains resolving to anything, including 127.0.0.1 or ::1. Alternatively you can even use http-01 or other challenges to get a wildcard cert, with subdomains pointing to localhost. I use Lets Encrypt certs for localhost and LAN every day.

Edit: a little more precision.

No, they blocked (now reverted) a specific list of domains which are presently known to resolve to 127.0.0.1. The actual IP address isn't used, it's a DNS block.