Home / Blogs

How Not to Take Russia Off the Internet

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 and Quad9’s, 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.

By John Levine, Author, Consultant & Speaker

Filed Under


Russian sanction blacklist Anthony Rutkowski  –  Mar 7, 2022 10:24 AM

What seems clearly needed if for the government authorities in relevant jurisdictions, e.g., U.S. and EU, to develop a Russian Sanction Blacklist the enables organizations and ISPs to block specific domains and IP address blocks by whatever means they have at their disposal.  Such an action would also provide requisite notice, be carefully tailored, and be enforceable.

Some bad ideas just won't go away John Levine  –  Mar 7, 2022 10:50 AM

The US has never attempted to block resolution of .CU or .KP or .IR or any other ccTLD of a country subject to US sanctions. "This time is different" is rarely a persuasive argument.

Yes, but Anthony Rutkowski  –  Mar 7, 2022 10:54 AM

An explicit Russian Sanction Blacklist is the appropriate course of action.  It provides specificity, rationale, notice, and actionability in one tidy package.

.RU redelegation could work ... but Karl Auerbach  –  Mar 8, 2022 1:25 PM

It *is* possible to achieve a form of redelegation of .ru that could work.

The goal would be to add friction, in the form of delay, to DNS query/response cycles for names in .ru.  Things would still work, but would be slow.  And it would not afflict everyone resolving names in .ru.

The goal is to be a nuisance to many, not a hard barrier to all.

Here’s how:

1. Redelegate .ru so that it’s NS records point to a new set of name servers under non Russian control.

2. Those new servers would begin life with an empty .ru zone.  (It being presumed that they could not simply do a zone transfer from one of the old servers.)

3. Those new servers would run a modified version of BIND or other DNS resolver such that whenever they got a query for a subdomain in .ru they would run a background fetch to the *old* servers to get the desired information.  They would also then incorporate that response into their own notion of the .ru zone.

4. When one of these new servers got a query for a subdomain in .ru, in addition to any time to fetch absent contents, would delay the response for a time, perhaps a second.

This, of course would take some programming - probably a couple of very long days - and the deployment of some new name servers.  The hardest part of the coding would probably be adding that response delay in a way that didn’t clog the server.  Of course, in overload situations one could simply drop the response knowing that the client will almost certainly retry.

A much easier to implement alternative to the delay is to simply randomly drop a percentage of the responses.

Russia could take countermeasures, such as blocking the inquiries from the new servers.  But that countermeasure could be circumvented by doing the fill-in-the-gap queries from a diffuse cloud of ever-changing addresses.

Or Russia could deploy its own root servers (for clients within Russia) that would refuse to honor the .ru delegation.  Many fear that this would be “splitting the root” form of Internet fragmentation.  But it’s not at all clear that this has not already happened in Russia or elsewhere.

Why? John Levine  –  Mar 8, 2022 1:33 PM

This just seems petty. Unless you plan to drop the TTL of everything to one second, it also wouldn't work, since after the first delayed response, answers come from a local cache.

Yes, I forgot to drop TTL, but that's easy Karl Auerbach  –  Mar 8, 2022 10:17 PM

Yes, I forgot to drop the TTL, but that's pretty easy to do. And if it causes (as it will) the load to increase, well, that's pretty easy to handle as well.

Still seems petty John Levine  –  Mar 9, 2022 10:04 AM

Also, you might want to check how effective DNS caches are. If you drop TTL from an hour to a second you're going to get a *lot* of queries and DDoS your caches.

Russia Root Servers Mike Burns  –  Mar 8, 2022 1:54 PM

https://www.reuters.com/technology/russia-disconnected-global-internet-tests-rbc-daily-2021-07-22/ "Many fear that this would be “splitting the root” form of Internet fragmentation. But it’s not at all clear that this has not already happened in Russia or elsewhere." Yes, it has happened already, starting back in 2019. Russia has their own root server copies.

TTL is easily tunable Karl Auerbach  –  Mar 9, 2022 10:28 AM

Yes, caching is good.  However the TTLs can be tuned so that the query rate is acceptable.

Most web based apps tend to concentrate an intense burst of queries within a short span - less than a second.  So I’d start with a TTL of a couple of minutes and work up or down from there so that most users will encounter a delay only once every few minutes.

Moreover, since this is an effort to cause annoyance, cache misses and lost queries (that have to be retried) are all part of adding friction but not completely destroying the service.

And we know that Russia would install overrides back to its usual servers for users within the country so this proposal would afflict mostly queries resolved outside of Russia.

Again, this is intended to be an annoyance - sort of like washing someone’s clothes with a bit of fiberglass cloth, it’ll itch like crazy but the clothes can still be worn.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byVerisign

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC


Sponsored byDNIB.com

Domain Names

Sponsored byVerisign