Member Avatar for Reverend Jim

I have been using my HOSTS file for years to dummy out ad sites by adding entries like

127.0.0.1   www.ukbanners.com

A while back I installed Unchecky, a program which automatically unchecks all of those software extras that some installers like to enable by default (like McAfee). Today I noticed nthat Unchecky added entries like

0.0.0.0 media.opencandy.com

to the end of my HOSTS file. A google search resulted in conflicting and ambiguous information as to the use of 0.0.0.0. The most complete explanations (in geek-speak) are usually of the "it depends" variety. Can anyone explain, in non-technical terms, the difference between a HOSTS entry of 127.0.0.1 and 0.0.0.0.

  • 4 Contributors
  • 4 Replies
  • 1K Views
  • 17 Hours Discussion Span
  • Latest Post Latest Post by Reverend Jim

Dani AI

Generated

Short answer: 127.0.0.1 is the loopback address — traffic sent there is intended to stay on the same host (localhost). 0.0.0.0 is the IPv4 “unspecified” or non‑routable placeholder; when used as a destination it indicates “no valid target” and is commonly used to nullify or short‑circuit name resolution. (serverfault.com)

Why people see different results: mapping a hostname to 127.x.x.x will route the request to the machine’s loopback interface and therefore can reach any local service that’s listening. Mapping it to 0.0.0.0 tells the stack “don’t route this out” so the connection typically fails immediately (faster and less likely to hit a local server). That said, behaviour depends on the OS and kernel — and ’s tests reflect exactly that variability. On many Linux systems the kernel treats a 0.0.0.0 destination specially and will end up using the loopback device in practice; other systems simply report “no route.” (unix.stackexchange.com)

Practical advice: for large blocklists most maintainers prefer 0.0.0.0 because it’s generally faster and avoids accidentally connecting to a local web server. If something odd appears (ads still load or a local service answers), try switching that host to a loopback address or enforce the block at the DNS/firewall level instead. After editing hosts, flush the OS and browser name caches (for Windows use ipconfig /flushdns; Linux varies by resolver). If unexpected behavior continues, test name resolution with nslookup/dig and check which resolver/hosts order your OS uses. (proprivacy.com)

Recommended Answers

All 4 Replies

Member Avatar for rproffitt

While we could go on and on, consider this ping result.

C:\>ping 0.0.0.0
Pinging 0.0.0.0 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for 0.0.0.0:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>ping 127.0.0.1
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

So think about this. 127.0.0.1 actually exists and if there is a server on your machine then it can get the message.
Now look at 0.0.0.0. It just fails. This is a good thing if you want the packets bound for candyland.com to just die.
And yes, how this works depends on the OS and it's IP stack so you can open a discussion on that and end up with a dissertation.

commented: Wish I'd thought of trying that ^_^ +14
Member Avatar for cereal

Just to support rproffitt's, on Ubuntu 16.04 it redirects to 127::1:

» ping -c 3 0.0.0.0                                                                                       
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.055 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.048 ms

--- 0.0.0.0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.029/0.044/0.055/0.011 ms

On Mac OS it fails:

$ ping -c 3 0.0.0.0
PING 0.0.0.0 (0.0.0.0): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
^C
--- 0.0.0.0 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
commented: Thanks for the tests. +12
Member Avatar for happygeek

Also see this (something I wrote about the insecurity of localhost a couple of months back for SC Magazine):

A Google engineer, Mike West, obviously doesn't think that the 127.0.0.1 domain is secure enough. West has submitted a standards draft to the Internet Engineering Task Force (IETF) seeking to formalise treating localhost in a secure context. In his draft, West wants to update RFC6761 so that the localhost domain and any names falling within it resolve to a loopback address. "This would allow other specifications to join regular users in drawing the common-sense conclusions that localhost means localhost" West insists "and doesn't resolve to somewhere else on the network."

Member Avatar for Reverend Jim

I just heard back from Michael Maltsev (Unchecky author) and he said that they are now using 0.0.0.0 because of a change to the TCP loopback interface in Windows 8.1. As rproffitt and cereal pointed out, a reference to 0.0.0.0 fails immediately (thanks for the tests - should have thought of that myself).

commented: Do you expect me to talk? Computer answers "No, Mr Packet, I expect you to die!" +12
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.