When an IP Block Takes Down a Country
In late August 2022, Cloudflare’s customer support team started hearing from users in Austria who couldn’t reach sites on our network. From the outside, it looked like a partial Internet outage in the country. It wasn’t a technical fault. As media reports later revealed, an Austrian court had ordered local ISPs to block 11 of Cloudflare’s IP addresses. No notice was given to Cloudflare in advance.
The court’s goal was to block 14 websites that copyright holders said were infringing. The method—blocking the IP addresses those sites shared with thousands of others—left ordinary Austrians unable to reach a far larger set of unrelated websites for two days. Those sites did nothing wrong. They were collateral damage from an approach to content restriction that ignores how the Internet is actually built.
IP blocking is not rare. It happens regularly around the world, but it usually goes unnoticed unless it takes down a lot of sites at once. Even Cloudflare, with deep technical visibility into how blocking works, can’t routinely see when one of its IP addresses is blocked. For everyday users, the situation is even more opaque: they typically have no way to know why a site won’t load, where the failure is occurring, or what they can do about it.
Collateral Damage at Scale
Freedom House’s “Freedom on the Net” report found that 40 of the 70 countries it examined—ranging from Russia, Iran, and Egypt to Western democracies like the United Kingdom and Germany—did some form of website blocking. The report doesn’t detail methods, but many of those countries use IP blocking, with the same potential for partial Internet shutdowns that Austria experienced.
Quantifying the damage is hard, but some organizations have tried. The European Information Society Institute, a Slovakia-based nonprofit, reviewed Russia’s website-blocking regime in 2017 for a case before the European Court of Human Rights. Russia used only IP addresses to block content. The institute found “collateral website blocking on a massive scale”: as of June 28, 2017, more than 6.5 million Internet resources were blocked in Russia, and 97% of those had been blocked collaterally, without legal justification.
In the UK, overbroad blocking led the Open Rights Group to create Blocked.org.uk, a site where users and site owners can report overblocking and ask ISPs to remove blocks. The group has collected hundreds of individual stories from charities and small businesses whose sites were wrongly made inaccessible—a dressmaker, watchmaker, or car dealer can’t attract new customers if local users can’t reach the website.
The obvious-sounding fix is to ensure restricted sites never share an address with unrestricted ones. That ignores a fundamental mismatch: there are far more possible domain names than available IP addresses, and the Internet’s technical specifications were designed around that decoupling. What counts as “restricted” also differs across jurisdictions, so no IP address allocation could ever satisfy every country’s rules.
Legal and Human Rights Consequences
Overblocking isn’t just an inconvenience. Courts and regulators have a legal obligation to make sure their orders are necessary and proportionate and don’t sweep in people who are not contributing to the harm. A court wouldn’t issue a search warrant based on a street address without checking whether that address was a single-family home, a six-unit condo, or a high-rise with hundreds of separate units. Yet that is exactly how IP addresses are often treated.
The European Court of Human Rights considered precisely this issue in 2020. A website owner in Russia had been blocked not because the government targeted the site, but because it shared an IP address with a blocked website. The court ruled that the indiscriminate block “amounts to arbitrary interference with the rights of owners of such websites”—that it was improper for a government to block sites that were not targeted.
Why Use Infrastructure to Police Content?
Most people don’t think about how content reaches them. They assume that typing a domain name into a browser will reliably produce the website. If it doesn’t load, they assume the site is having technical trouble—not that their ISP has been ordered to block it. But connections to websites are routinely used as a control point for limiting access to online content.
Countries block for many reasons: to restrict gambling or explicit material that is legal elsewhere, to prevent citizens from seeing foreign news outlets accused of spreading disinformation, or to enforce copyright claims. It’s worth being clear that blocking is not the same as removing content and that in many legal systems, blocking is meant to be a last resort, after attempts to remove content at the source have failed. The blocked site remains online and accessible to everyone else; only users whose ISP is ordered to block lose access.
We understand the concerns that drive blocking orders. Even so, users should know when and why sites have been blocked, and restrictions should be as limited as possible to avoid infringing the rights of others. Brute-force IP blocking offers none of that. It is opaque to users, unavoidably affects other content, and, by design, gives no reliable way to predict which other websites will be caught up in a block.
Understanding what happened in Austria requires getting into the technical details of how the Internet is put together.
Names, Not Addresses, Are the Identity
The best first option for dealing with problematic content is at the source. A website owner or hosting provider can remove content at a granular level, or a domain name registrar or registry can withdraw a domain name entirely. When the content owner is unwilling or unable to remove content, there are only three control points left for blocking access to a website.
The first is the Domain Name System (DNS), which translates domain names into IP addresses. A DNS resolver can refuse to return a valid address and respond with NXDOMAIN (“no such name”). A more honest approach would use one of the error codes standardized in 2020—15 for blocked, 16 for censored, 17 for filtered, or 18 for prohibited—though these are not yet widely used. Precision depends on whether the resolver is private or public. Private resolvers, operated by ISPs and enterprises for known clients, can apply restrictions with some accuracy. Public or open resolvers cannot, because routing and addressing on the global Internet are constantly changing in ways that a fixed map cannot capture.
The second approach is to block individual connection requests to a restricted domain name. When a client initiates a connection to a server name, a network or on-path device that can observe the server name can terminate the connection. But there is no mechanism to tell the user that access was blocked or why.
The third approach is to block access to the IP address where the domain name is found. This is like stopping delivery of all mail to a physical address—say, a skyscraper with many unrelated occupants. Halting delivery to the building affects everyone in it. IP addresses work the same way.
Critically, the IP address is the only one of the three options with no necessary attachment to a domain name. Domain names aren’t needed to route data packets; they are fully ignored in routing. A website can be available on any IP address, or on many at once, and the set of addresses can change at any time. It cannot be definitively known by querying DNS, which has been able to return any valid address for any reason since 1995. The very idea that an IP address represents an identity is antithetical to the Internet’s design, which is built on the deep decoupling of names from addresses.
IP addresses were never meant to identify websites
The persistent confusion stems from an understandable but outdated assumption: that one IP address equals one website. In the early Internet, that was often the case — one computer, one interface, one address, one name. But that one-to-one mapping was an artifact of the deployment environment, not a property of the protocols themselves.
The protocols always allowed multiple names on a single host. Early on, a server might carry names like mail.example.com and www.example.com, sharing a base domain. The real change came when completely unrelated domains began sharing servers. The Host header in HTTP/1.1 (1997) made this practical, and the SNI field in a TLS extension (2003) carried it forward into encrypted traffic.
Throughout these shifts, IP and DNS have stayed fundamentally unchanged — and that's by design. They handle addresses, reachability, and arbitrary name-to-address relationships. The two protocols are entirely independent, which reinforces a core point: names are separate from addresses. A closer look at the protocol specifications makes the misperception clear.
Reachability is IP's only job
The Internet runs on open standards published by the Internet Engineering Task Force (IETF) as "Requests for Comment" — RFCs. The name reflects that standards must evolve with experience, not that they're incomplete. RFC 1 appeared in 1969; the Internet Protocol specification reached RFC status in 1981.
That same year also saw the end-to-end (e2e) principle codified, based on years of practical trial and error. The principle distills to a core idea in the IP specification: the network's only responsibility is reachability. Every other feature carries a cost or a risk. RFC 791's Section 2.3 is explicit that IP addresses have no inherent association with names or interfaces.
Addressing
A distinction is made between names, addresses, and routes [4]. A
name indicates what we seek. An address indicates where it is. A
route indicates how to get there. The internet protocol deals
primarily with addresses. It is the task of higher level (i.e.,
host-to-host or application) protocols to make the mapping from
names to addresses. The internet module maps internet addresses to
local net addresses. It is the task of lower level (i.e., local net
or gateways) procedures to make the mapping from local net addresses
to routes.
[ RFC 791, 1981 ]IP addresses are like street addresses on an envelope. You can't know what's behind them. On a network like Cloudflare's, a single IP address can represent thousands of servers and millions of websites — precisely because the protocol is designed to allow it. Could a provider guarantee a one-to-one name-to-address mapping? No, and again the reason is protocol design — this time DNS.
DNS names outnumber addresses by design
A strict one-to-one relationship between names and addresses is impossible for the same reason it's infeasible in the physical world: there are more people and organizations than postal addresses. The Internet needs to accommodate more names than addresses — and the specifications guarantee it will.
IPv4 addresses are 32 bits; IPv6 addresses are 128 bits. A DNS domain name can be up to 253 octets, or 2,024 bits (per RFC 1035, Section 2.3.4, published 1987). The magnitude difference is stark:
When the United Nations announced in November 2022 that the planet's population surpassed eight billion, the point was intuitive: there can't be anywhere near that many postal addresses. The same logic holds for names versus addresses on the Internet — and the protocol designs make the imbalance permanent.
What the data says about overblocking
An Austrian IP-blocking incident from late August 2022 illustrates the problem. To restrict access to 14 target domains, authorities blocked 11 IP addresses (source: RTR.Telekom. Post via the Internet Archive). The mismatch between 14 names and 11 addresses was an early warning that the approach would have side effects.
To quantify the scale, we generated a global view of domain names and IP addresses. In September 2022, using authoritative zone files for the top-level domains (TLDs) .com, .net, .info, and .org, plus top-1M website lists, we found 255,315,270 unique names. Querying DNS from five regions, we recorded the IP addresses returned:
The results are striking. No more than 10.7 million addresses are needed to reach all 255,315,270 names from any single region; the total set of addresses across all regions is about 16 million. The ratio of names to IP addresses is nearly 24x in Europe and 16x globally. And since these figures combine IPv4 and IPv6, far fewer IPv4 addresses alone would be needed.
Looking at the data differently reveals more. The cumulative distribution below shows the proportion of websites reachable as IP addresses are added, ranked from those hosting the most domains to the least. The addresses with the most domains number in the eight-digit millions.
Some observations stand out:
- Fewer than 10 IP addresses reach 20% of domains — about 51 million.
- 100 IPs reach almost 50% of domains.
- 1,000 IPs reach 60% of domains.
- 10,000 IPs reach 80%, or about 204 million, domains.
Of the 16 million total addresses, only 7.1 million (43.7%) had just one name in our dataset. And even that number is misleading — our dataset only covered four TLDs and top-1M lists, so those addresses could easily host additional names we didn't see.
IP addresses also change over time for performance, security, and reliability reasons — load balancing alone means DNS queries return different addresses for the same website at different times or locations. That gives IP blocking another failure mode: it goes stale.
There is no reliable way to know how many domains sit on an IP address without inspecting every name in DNS from everywhere on the planet at every moment — an infeasible proposition. Any action on an IP address must, by the protocols' own definitions, have collateral effects.
Why overblocking persists
If IP blocking inevitably causes collateral damage, and overblocking is widely agreed to be inappropriate or even legally impermissible, why does it continue? We can only speculate. Sometimes it's a lack of technical understanding among decision-makers like judges who aren't technologists. Sometimes governments simply accept collateral damage — as with Internet shutdowns — because the blocking serves their interests. And when collateral damage occurs, it's rarely visible from the outside, so there's little external pressure to fix it.
That opacity is worth stressing. When an IP is blocked, a user sees only a failed connection — no explanation of why it failed or who caused it. The server operator doesn't even know it's been blocked until users complain. There's virtually no transparency or accountability for overblocking. Challenging a block or seeking redress can be nearly impossible for a website owner.
Some governments, including Austria, publish active block lists, which is a step toward transparency. But publishing an IP address doesn't reveal all the sites unintentionally blocked behind it, nor does it give those affected a way to challenge the overblocking. It's hard to imagine a court order on a physical skyscraper that wouldn't be posted at the door — yet in virtual space, due process and notice are routinely skipped.
The problem is becoming more urgent as more countries push to block content online. ISPs often implement those requirements with IP blocks because it's the least effort and is readily available in most networking equipment. Larger ISPs do it too. As more domains share the same finite set of IP addresses, the collateral damage will only grow.
Where IP blocking goes wrong, and what to do about it
IP address blocking is a blunt instrument, and its collateral damage is rarely visible. Even when the intent is to restrict a single domain or service, the reality is that blocking an IP address often sweeps in unrelated sites hosted on the same infrastructure. The result is that legitimate content becomes inaccessible along with the targeted material, a problem we see repeatedly in network data.
The core issue is that IP addresses are not content labels. They are routing identifiers. One address can host thousands of domains, each with no relationship to the other. When an IP is blocked, all of those domains are affected, not just the one that drew attention. This is not a hypothetical edge case; it is a structural consequence of how the Internet is built.
Why legal mechanisms matter more than technical ones
To address illegal content, countries need legal mechanisms that can remove or restrict content in a rights-respecting way. The legal path is the right one because it gives authorities the ability to act on the specific content, the source hosting it, and with due process. Laws such as the EU's Digital Services Act and the Digital Millennium Copyright Act are designed for this purpose.
Governments should focus on legal tools that minimize the impact on other people's rights, aligning with human rights expectations. These mechanisms target the content itself or the entity responsible, rather than the underlying network infrastructure. This is the approach with the fewest side effects.
An Internet-wide problem needs an Internet-wide response
The scale of the problem makes it an Internet-wide issue. Because the collateral damage from IP blocking is so pervasive, addressing it requires more than a single technical fix. It takes a coherent, multi-stakeholder effort to change the default behavior and highlight the harm caused.
We are working with civil society partners and like-minded companies to speak out against IP address blocking as a method for solving content challenges. When the practice causes unintended restrictions, we aim to point that out and build broader awareness of its consequences. We also believe that greater transparency is a practical first step. While there is no comprehensive way to fully document the collateral damage from IP blocking, awareness can be expanded through initiatives like the Cloudflare Radar Outage Center, which help surface when network activity is disrupted unexpectedly.
The simple conclusion is that content policy needs cannot be met by blocking IP addresses. Addressing content at the source is almost always the necessary and required first step. That is where the legal frameworks already exist, and where the tools are capable of precise action.
For a closer look at network disruptions, Cloudflare Radar offers live insights into what we observe across the Internet, including when access is limited beyond the intended target.
