Should 0.0.0.0 be replaced with an explicitly invalid IP address? about hosts HOT 11 CLOSED

+1 For this whole conversation.

To my (limited) knowledge, this issue has never been properly resolved by any of the many attempts at discussing it. It's really kind of amazing giving it's importance and prevalence.

Over the years, I have read many "conclusive" answers, all coming to different conclusions.

Unless there is an accurate source of an answer that has actually been implemented by hardware and software vendors, it seems like the most prudent approach is to determine what actually works reliably and has the lowest latency. This may vary across operating systems, and perhaps even versions of operating systems. In some cases, hardware variables may play a role as well.

Maybe we can start a crowd-sourced fund to finally answer this mystery of the internet.

from hosts.

@nerai you make an interesting point.

The way I'm currently understanding RFC 5737, it's hard to see how it applies in this case, though I still feel you make a valid point.

The 0.0.0.0 arose from a similar suggestion, along with metrics that show faster response than 127.0.0.1 on some OS.

What I'd love to see is and RFC that specifies an IP address equivalent of dev/null :-) Failing that, I'm happy with an IP address that exhibits best performance in many or most cases. Because, all things being equal, raw performance always counts.

from hosts.

@nerai I'm leaning towards following RFC 3330 and dish to an address in 0.0.0.0/32 other than 0.0.0.0.

Presuming resolution times are the same, which I suspect will be true.

EDIT turns out 0.0.0.0/32 is 0.0.0.0, amiright?

from hosts.

@StevenBlack My understanding is that 0.0.0.0/32 is the network address of the whole internet.

I've since learned that it seems RFC 2644 makes directed broadcasts (i.e. to a foreign network address) invalid.

A router MAY have an option to enable receiving network-prefix-
directed broadcasts on an interface and MAY have an option to
enable forwarding network-prefix-directed broadcasts. These
options MUST default to blocking receipt and blocking forwarding
of network-prefix-directed broadcasts.

So unless you're running a (very) nonstandard configuration, 0.0.0.0 should be fine. I suppose this ticket can be closed.

from hosts.

Just out of interest, which OS's timed out on 127.0.0.1? I've not been able to replicate this behaviour on Windows, Linux, FreeBSD nor Solaris. From what I understand of networking, a connection request would only timeout if there was routing issues (not applicable here) or a process was listening on that IP + port and that process was timing out the request. If there's no listening processes on 127.0.0.1:80 / :443 then your connection request (eg curl / firefox / etc) will fail pretty much instantly due to the kernel refusing the connection.

There is an argument for using 0 as it's quite common for processes to open listening processes on localhost, but IIRC some HTTP daemons (eg Apache) actually default to 0 (you'd obviously expect sysadmins to change this, but that doesn't always happen for many less experienced developers (eg the kind of people who might install XAMPP).

So arguments of timeouts aside (happy to be proven wrong here), the question of 0 or 127.0.0.1 really boils down to personal preference more than anything.

From an academic perspective, the safest way to proceed here would be to assign a virtual IP and have firewall rules that refuse any connection to it. However that's obviously completely outside the remit of this project. But in terms of what you have done already, it looks pretty good :)

from hosts.

One thing I haven't seen discussed (apologies if it has and I've missed it) is what personal firewalls / anti-malware packages people are running. These can obviously directly impact how a connection request to localhost / 0 is handled, as well as how outgoing connections.

For example, sometimes administrators / developers will configure their firewalls to drop traffic[1], and other engineers might configure them to refuse traffic[2]. There's arguments for and against each solution but it often just boils down to personal preference.

[1] dropping traffic will cause timeouts since you're just dropping the packets without sending a response.

[2] refusing traffic will cause an instant fail (connection refused) as it returns connection attempts (syn packets) with a reset packet (rst). This is how TCP/IP stacks typically work by default; ie if no firewall present and no listening process on that IP + port.

from hosts.

To clarify, the calls to 127.0.0.1 don't "time-out", per-se, but take non-zero time to resolve, presumably because waiting for a response requires some time. Someone reported testing shows resolving 0.0.0.0 was quicker.

Just as an example, ping on Ubuntu 15.10 shows consistently faster mean times for 0.0.0.0 (0.057 ms) compared to 127.0.0.1 (0.074ms) but that's anecdotal, my results on my machine, just now. Still, this is 0.02 ms difference which, in the scheme of things, doesn't matter so much.

On OSX when I ping 0.0.0.0 I get ping: sendto: No route to host error which I suspect is faster than executing the route, but that's just my guess.

from hosts.

I think we can close this now.

from hosts.

I run a dev webserver on 127.0.0.1. How can I keep the blocked hosts domains from clogging up my local web logs, which are critical for debugging?

from hosts.

@hopeseekr Why do you run it on 127.0.0.1?

from hosts.

@hopeseekr

Just change the IP. You could try 0.0.0.0 or better yet, use valid IP outside of your subnet range, eg like 192.168.254.1 (assuming your LAN isn't 192.168.254.0/24).

If you're running Linux or OS X then you can just sed it:

$ sudo sed -i -r 's/127\.0\.0\.1/192.168.254.0/g' /etc/hosts

If you're running Windows then just do a find and replace in your favourite text editor.

@Gitoffthelawn:

It's pretty common to run dev servers on localhost when you're a one man dev team.

from hosts.