Document reasoning to block DNS to 127.0.0.1 • Hacker News Board

Re: Document reasoning to block DNS to 127.0.0.1

#41

Post by SahAssar » Tue, Jun 20, 2023, 2:22 PM UTC

jeroenhd wrote: post #31

SahAssar wrote: post #17

Earlier quoted context omitted.

> 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) Of course you can, you just cant use HTTP validation for it. Use DNS validation and it works fine.

Not if you don't control the DNS. I don't know who controls fbi.com but I sure can't get a trusted certificate for it

That was not the point you made in the original post. You said

> 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) so development doesn't even reflect real life deployments. Secure origins matter!

So you can absolutely make development match deployments.

Re: Document reasoning to block DNS to 127.0.0.1

#42

Post by Alupis » Tue, Jun 20, 2023, 4:55 PM UTC

adamckay wrote: post #37

Alupis wrote: post #21

Earlier quoted context omitted.

I've got to ask - if you're doing local dev or whatever, what's so hard about turning ublock off for your dev site? The logic seems ok for "out in the wild" cases - but ublock still let's you override stuff if you know what you're doing.

At a previous job I worked on a web-based file sharing app, and to share individual files we used a generic share icon from the font awesome project with appropriate labels. We got a bug report from someone in the company that the share icon was missing, and after investigating we saw the other icons (for edit and delete) were visible but not sharing. Long story short, they used an adblocker with a setting to block s…

In my experience, ublock breaks an awful lot of sites you have to use, such as your payment processor website, sales channel manager sites, etc. For me, at least, if a website seems to not be working quite right, I disable ublock and try again after a refresh.

I guess you could call those "trusted" sites perhaps.

Re: Document reasoning to block DNS to 127.0.0.1

#43

Post by charcircuit » Tue, Jun 20, 2023, 7:26 PM UTC

binary_ninja wrote: post #35

charcircuit wrote: post #3

This is not the right way to block domains that resolve to local addresses even if that was something you desired to do. If you know the IP you want to block you should just block on the IP instead of chasing down every possible address even though addresses can change at any time.

are you suggesting to block 127.0.0.1?

If you want to block requests to 127.0.0.1 DNS is the wrong level to do it

Re: Document reasoning to block DNS to 127.0.0.1

#44

Post by hnbear » Tue, Jun 20, 2023, 10:37 PM UTC

jeroenhd wrote: post #32

hnbear wrote: post #11

Earlier quoted context omitted.

I thought about the cert thing here too. I own a domain and internally use local.domain.com for all internal sites. Wildcard and specific names. I can generate certs using ACME/LetsEncrypt. So, everything, including test sites could be on that domain. For reference, I use PiHole and OpnSense, and internally machines in DHCP and static IPs get local.mydomain.com resolution too.

You can generate valid certificates for the domains you own and make the DNS point at anything you like. It's quite a pain for a dev setup (LE certificates only lasting three months, so long enough to forget about your setup but short enough that you'll need to keep running it). In this specific case, it's about, a bunch of generic domains set up by other people. In your pihole example the situation would be even bet…

Yeah, it definitely introduces friction and setup cost.

OpnSense has an ACME plug-in to auto-renew, and can trigger jobs. In this case I have it renew and push certs to servers so they’re always renewed.

Re: Document reasoning to block DNS to 127.0.0.1

#45

Post by halJordan » Wed, Jun 21, 2023, 4:11 PM UTC

albert_e wrote: post #23

LinuxBender wrote: post #12

Earlier quoted context omitted.

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 sill…

> park wildcard sub-domains on 127.0.0.1 that sounds like a good practice -- why is this not done more often I wonder. EDIT: on a second thought i am not so sure. I am not an expert here so I will not try to guess :)

Private IPs should not be publicly routable. For one, you are no longer standards-compliant. If you want to depend on the IPv4 standard, you've already broken what you're trying to depend on.