To answer the question as asked, which is about the lines in /etc/hosts rather than about the use of the IP address ranges (which is not altered by adding or deleting things from /etc/hosts):
The point of these lines is to handle the address→name lookups of those addresses, and show these names to humans in output.
What is doing the address→name lookups
Every time that a tool like netstat -r or ifconfig or arp (or various others, varying by operating system and networking toolset) runs it performs reverse lookups on the IP addresses assigned to network interfaces, routing table entries, and ARP table entries; in order to display names instead of numbers to humans. Some of these tools are smart about loopback, link-local, unique-local, and site-local IP addresses; and will not try to display domain names for them, as they do (absent the tools's various -n options being employed) for other IP addresses (both versions 4 and 6).
Some are not.
A non-smart tool, with no -n option, ends up calling the C library's old gethostbyaddr() function or more modern getnameinfo() function with these IP addresses. In turn (but with a notable exception), according to the C library's NSS configuration, this ends up as either a files lookup in /etc/hosts or a dns lookup in the Domain Name System, or both. (Or more besides. If there's a systemd source in the NSS switch, the lookup ends up going through a Desktop Bus broker process and a systemd-resolved process and thence back to the Domain Name System, mDNS, LLMNR, et al.)
What the public DNS has
The public Domain Name System does not contain address→name mappings for these IP addresses.
The ip6.arpa. content DNS servers run by ICANN and the IAB simply respond "no such domain" for 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (the domain name that is actually looked up when something tries to use the DNS to map the IP address ff02::1 to a name) and its ilk. Usually this results in NSS falling back to its next lookup method, listed after dns (or systemd-resolved trying something else).
Just saying no to doing these lookups
It is to varying extent problematic that these lookups are even made at all.
- It is a leak to the outside world of local operations.
- Although individually tiny, the cumulative load on the
ip6.arpa. content DNS servers from all of the systems in the world leaking these address→name lookups for these IP addresses is significant. - Because of the way that the Domain Name System works, there is also a significant global load on IAB's+ICANN's
arpa. content DNS servers and the . content DNS servers. - Going to mDNS, LLMNR, DNS, et al. for this is pointless, as the resultant names given to humans are — ironically — well-known, invariant, and common to many systems.
Four major coping strategies have been around for decades:
- The notable exception, mentioned above, is the BSDs.
getnameinfo() in at least FreeBSD and NetBSD (and their derivatives) simply short-circuits address→name lookups for IP (4 and 6) link-local and multicast addresses, entirely. They do not even get as far as the NSS switch in the C library, let alone out to any DNS server. (localhost is short-circuited in the name→address direction, for comparison.) - Since just past the start of the 21st century, Felix von Leitner has provided modifications to Daniel J. Bernstein's
dnscache program from djbdns, to make it internally synthesize answers for these address→name mapping queries. Any DNS lookup that goes through such a dnscache will never hit the outside world and never load any ICANN/IAB server. The Bernstein original was already synthesizing a name→address result for 127.0.0.1.(Other DNS server softwares synthesize answers to special domain names to greater or, mostly, lesser extent, too. There was an RFC on this in 2013, encouraging such synthesis after djbdns pioneered it. Sadly, it was in the usual state for DNS RFCs: half-baked. It completely omitted any consideration of ip6.arpa. and forgot about 127.in-addr.arpa. even though it discussed 10.in-addr.arpa. et al..)
- For about the same length of time I have been providing instructions on the bare minimum for split-horizon DNS service; including splitting out the special domain names used for such IPv4 and IPv6 domain name mappings of loopback and local IP addresses.
Indeed, there is so much routine use of non-public IP addresses, both version 4 and 6, nowadays that everyone should employ one of these. If one is not using one of those BSDs, then one should definitely deploy a minimal split-horizon DNS service to prevent all of this non-public stuff leaking off one's LAN. It is a less heavyweight mechanism than having a PiHole or stuffing different firmware on a router are, and people have no qualms about those.
- As a sledgehammer-to-walnut measure, several operating systems have this stuff pre-loaded into
/etc/hosts as you have observed. - Not everyone agrees on these de facto names. The BSDs do not have them, obviously. But it's not just Debian Linux and its derivatives that has/had them. SuSE Linux had them at one point, too.
- The names seem to originate in Debian with the
netbase package from the days when it was being maintained by Andrew Towns. Some, but not all, of them were taken out in mid-2013 (although that change wouldn't have crawled through the process to a stable Debian by the time of the question). - In fairness, this stuff is from January 1999 according to the old netbase package changelog, and pre-dates djbdns by 11 months. ☺ And the removal of some of the names post-dated Felix von Leitner's work (using the same Debian names) by over a decade.
If you go and read RFC 882 from 1983, you will see that Paul Mockapetris's original idea was to obviate a HOSTS.TXT file that everyone had to have a copy of, with common universal names in. And yet it is 2025 and here we are. ☺
jdebp@debian %tail -n 4 /etc/hosts # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters jdebp@debian %
Further reading
