Artículos del equipoPoder y gobernanza

What is Internet governance risk? A practical guide

Start with one service your customers use. Identify who controls its names, addresses and routing, then test what happens when a dependency fails.

Índice

A hand holds a magnifying glass over a cable linking a miniature shop to a server; a register and keys lie nearby.
Start with one service customers use. Trace its names, addresses, connections and records, then test what happens when one dependency fails.

Internet governance risk is the possibility that decisions or failures in the institutions, rules and services your organization depends on will disrupt its ability to operate online.

The simplest place to start is one question: if an outside party could no longer perform its role tomorrow, what would stop working for your customers?

Start with one service people use

Choose something concrete: a customer login, a payment connection, an API or an office connection. Write down what a user needs to reach it. That may include a domain name, DNS service, IP addresses, connectivity and a hosting provider.

A domain name is the human-readable name people use. DNS helps resolve that name to the information needed to reach a service. IP addresses and routing handle a different part of the journey. Losing control of a domain account, changing an IP address and losing a network connection are different failures.

Find out who can change each dependency

For each part of the service, identify both the organization providing it and the person who can make an essential change. An account in a former employee's name is one kind of risk. A supplier who alone can update your routing authorization is another.

  • Names: who controls the domain account, renewal and DNS records?
  • Numbers: who is recorded as the resource holder, and who can request changes?
  • Routing: which network announces the addresses, and who can change that arrangement?
  • Security assertions: who maintains the records used to check authorized routing?
  • Customer dependencies: which partners or customers have stored your current addresses in their own systems?

For example, a Route Origin Authorization, or ROA, records which Autonomous System Number may originate an IP prefix. A prefix is a block of addresses; an Autonomous System Number identifies a network in inter-network routing. The ROA specification defines that narrow authorization. It is not a general guarantee that traffic will arrive or that an entire route is safe.

Separate the failures you need to prepare for

A service failure means something is unavailable: a provider, an account or a necessary administrative function. Ask what keeps running and which changes become impossible.

A change in terms or policy means the relationship still exists but its conditions have changed. Ask which actual service or planned transaction is affected, rather than assuming every proposal has the same consequence.

A legal obligation comes from the laws that apply to your operations. It is a separate question from what a technical institution claims through its policies. In Note 4, on data sovereignty, Lu Heng distinguishes technical capabilities from legal authority. Locating a server in one country does not, by itself, settle every issue of access, control or jurisdiction.

Test the recovery path

Choose one interruption and walk through the response with the people who would carry it out. If a provider fails, can you move the service? If the IP addresses must change, which customers need to act? If registration updates are unavailable, what evidence and operational arrangements would you need?

Record the actual steps, the dependencies on other parties and the time the exercise took. A documented route that has never been tested is different from one your team can execute.

Some gaps are within your control: missing account access, an undocumented renewal or an untested provider change. Others are structural. Do not describe a registry replacement as available merely because you would like one to exist.

Turn the exercise into a better question

Lu Heng's proposal is that necessary coordination should remain narrow and replaceable. The same question can guide your review: does this arrangement help a network keep operating, or make it dependent on an administrator it cannot leave?

The exercise is complete when you can name the dependency, explain the effect on a customer and identify a tested response—or a specific gap that still needs a solution. That is more useful than a generic promise to monitor Internet policy.

Read Lu Heng's proposed rights for the coordination layer to see the wider change this points toward. For the introduction to the debate, return to why decentralisation matters.