Why Private IP Addresses Are Not Routable on the Public Internet

RFC 1918 set aside three IPv4 ranges -- 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 -- specifically for use inside private networks, precisely because there aren't enough public IPv4 addresses for every device on every private network to have a globally unique one. These ranges are reused, simultaneously, inside millions of unrelated networks worldwide. Your home router almost certainly hands out 192.168.x.x addresses; so does practically everyone else's.

What it means for a public domain to resolve into this range

Because these addresses are meaningful only within whatever local network is asking, a public domain that resolves to one is, at best, a misconfiguration -- and at worst, a deliberate attempt to get a public-facing system to make a request to whatever happens to sit at that address on its own internal network. The public internet has no consistent idea of what 10.0.0.5 even refers to; it's a different machine depending entirely on which network is asking.

• A legitimate public domain has no reason to ever resolve to a private-range address -- if you see one, treat it as a signal worth investigating, not a normal result.
• IPv6 has its own equivalent private/reserved ranges -- unique local addresses (fc00::/7) and link-local (fe80::/10) -- that need the identical treatment.

Filtering these ranges out at the point of resolution -- rather than trusting that a public-looking domain always resolves to a public-looking address -- is the baseline expectation for any tool that resolves domains on a user's behalf.

The range most blocklists forget

100.64.0.0/10 -- "shared address space," defined by RFC 6598 -- doesn't get anywhere near the recognition that 10.0.0.0/8 or 192.168.0.0/16 do, despite being just as unroutable on the public internet. It exists specifically for carrier-grade NAT, letting an ISP address large numbers of customer connections internally without consuming public IPv4 space for each one. Because it's newer and less well-known than the classic RFC 1918 ranges, it's the one most commonly missing from a hand-rolled blocklist -- exactly the kind of gap that only shows up once someone deliberately points a domain at an address inside it.

"Fail closed" matters as much as the list itself

A blocklist is only as good as what happens when an address can't be parsed at all. Malformed input, an unusual notation, or a value that doesn't cleanly match any known range should never be treated as "probably fine" by default -- the safe default is to reject anything that can't be confidently classified as public, rather than only rejecting addresses that positively match a known-bad range. This "fail closed" posture is what keeps a blocklist robust against the ranges nobody thought to add yet, not just the well-known ones already on the list.