Last week the Ukrainian government sent a letter to ICANN asking them to revoke the “.ru”, “.рф” and “.su” top-level domains. It also said they were asking RIPE, which manages IP addresses in Europe, to revoke Russian IP addresses. Both ICANN and RIPE said no.

Other people have explained why it would have been a policy disaster, but beyond that, neither would actually have worked.

The DNS is conceptually a tree with the contents of the root servers managed by ICANN. If you look up a name like bigbank.ru, your computer first asks a root server where the servers for “.ru” are, then asks one of those where “bigbank.ru” is, so if the roots stopped answering questions about “.ru”, those names would all disappear. Except it’s not that simple.

Your computer doesn’t do those lookups directly. Instead, it uses an intermediate DNS server known as a recursive resolver or a DNS cache. The cache receives the request from the client computer, queries the authoritative servers to find the answer, and sends the answer back. It usually also remembers the answers it got from the authoritative servers so it can reuse them (the cache part). Some caches have vast numbers of users like Google’s 8.8.8.8 and Quad9’s 9.9.9.9, while most are much smaller and just handle requests from a single network.

It is quite common for the cache to edit the set of names they handle. For example, many are set up not to resolve names that point to malicious sites. It is also common to add names, such as names for computers on one’s local network.

Were the global root servers to delete .ru, it would take about 15 minutes for someone to set up a cache that added it back in, and another 15 minutes for people who wanted to contact Russian web or mail users to configure their software to use it. It would not be quite as smooth as before, but it would not be a significant bar to anyone who cared.

Trying to revoke IP addresses would work even worse. While domain names conceptually work from the top down, IP allocations work from the bottom up. Every network knows what IP address ranges it handles, each network tells its neighbor networks both about its own addresses and about other networks it knows how to contact, and this route information percolates through the Internet using a variety of schemes, the most important of which is Border Gateway Protocol (BGP). As networks come online and offline and connections are created and broken, the BGP route information is updated accordingly.

This all works because the regional Internet registries and their predecessors have handed out ranges of IP addresses to each network. But what would happen if someone uses an IP range they haven’t been assigned and announce routes for it? That happens all the time, sometimes deliberately, sometimes by accident. While there is a security scheme called BGPSec, which is supposed to ensure that networks only announce routes to their own IP addresses, it isn’t widely used; there is no practical way to stop “rogue” route announcements.

So if RIPE were to revoke all of the IP addresses assigned to Russian networks, and those Russian networks continued announcing routes to their formerly allocated addresses, there’s not much anyone could do about it. Hypothetically RIPE could reassign the addresses to other people, but that would cause chaos with dueling route announcements, so it’s fortunate they won’t be doing that.

This isn’t to say other networks have to accept Russian traffic—no network has to accept traffic from anyone else, and if anyone wants to configure their own network to reject packets from Russian IP addresses, they can easily do that, and they don’t need help from ICANN or RIPE. But that is a policy decision for each network to make on its own, not one imposed from the outside.