Internet Infrastructure: Subsea Cables & DNS
Last updated 14 Oct 2026
At a glance
Two global systems sit under every operator’s services. Subsea cables carry the overwhelming majority of intercontinental traffic, owned by consortia of operators or, increasingly, by hyperscalers. The DNS root is the top of the naming system: thirteen identities, run by twelve organisations, answered from about two thousand anycast instances. An operator buys capacity on the first and runs resolvers against the second; it controls neither.
The picture
Two global systems under every operator’s services: the physical path between continents, and the top of the naming system.
A packet between continents · physical path
- Access & metro
The customer’s line or radio, aggregated
Operator
- IP core
Routes toward the international gateway
Operator
- Landing station
Powers the repeaters; line terminal equipment lights the fibre
Landing party
- Wet plant
Fibre pairs in armour, repeaters every 50–100 km
Consortium or private owner
- Far landing
Backhaul inland to an exchange or data centre
Landing party
- Peering / data centre
Where the traffic meets other networks
Carriers, clouds, IXPs
A name lookup · logical path, cached at the resolver
- Device
Asks for www.example.com
Customer
- Recursive resolver
The ISP’s, or a public one (8.8.8.8, 1.1.1.1); caches every answer
ISP or resolver provider
- Root server
Refers it to the .com servers; the nearest anycast instance answers
12 root server operators
- TLD server
Refers it to example.com’s servers
TLD registry (.com: Verisign)
- Authoritative server
Answers with the address
Domain owner or DNS host
Not one path
A lookup travels over whatever links routing chooses at that moment, often to a root instance in the same country. Nothing ties it to a particular cable.
How it works
Subsea cables
Subsea fibre carries the overwhelming majority of intercontinental data traffic; satellites carry a small share (TeleGeography, 2023). TeleGeography tracks more than 600 active and planned systems. A system is a few fibre pairs inside armour, with repeaters every 50 to 100 km boosting the light, powered from the shore.
- Landing station. Where the cable comes ashore. Power feed equipment drives the repeaters; line terminal equipment lights the fibre; backhaul carries the capacity inland to an exchange or data centre, where it meets networks.
- Owners. Traditionally a consortium of operators sharing the build cost, each taking fibre pairs or spectrum and a landing in its own country. Hyperscalers now anchor or wholly own many new systems for traffic between their own data centres.
- Buyers. Everyone else buys capacity: a long-term right of use (IRU) on fibre or spectrum, or a lease of wavelengths or circuits, usually on several systems for diversity.
- Faults. Most damage is accidental — fishing gear and ship anchors in shallow water. Repair ships are few, so a repair takes days to weeks; traffic moves to other systems meanwhile, if the operator has bought capacity on them.
The DNS root
The root zone lists the servers for every top-level domain (.com, .uk, .io). Its content is managed through the IANA functions and published by the Root Zone Maintainer; twelve root server operators serve it unchanged under thirteen names, a to m.root-servers.net (Verisign runs two). Thirteen names, not thirteen machines: on 2026-10-13 root-servers.org listed 2,031 operational instances in 179 countries.
- Anycast. Every instance of an identity announces the same address in routing (BGP); the network delivers each query to the nearest by routing distance. More instances mean shorter paths, and an outage or attack at one is absorbed by the rest.
- Global and local. A global instance is announced to the whole internet; a local one only to the networks peering with it, often at an internet exchange.
- Resolution. A device asks a recursive resolver (the ISP’s, or a public one such as 8.8.8.8 or 1.1.1.1 — resolvers, not root servers). With nothing cached, the resolver asks a root server, is referred to the TLD servers, then to the domain’s authoritative servers, which answer. Referrals are cached, so the root is asked rarely.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Cable system (wet plant, landings, fibre pairs) | The owners (consortium management committee or private owner) | — | Operator’s resource inventory, for its own share | The operator records what it owns or has bought, not the whole system. |
| International capacity contract (IRU or lease) | Wholesale contract and billing (BSS) | Carrier sales / capacity management | Resource inventory (the circuits it delivers) | Contract truth and circuit truth are reconciled by hand in most estates. |
| Root zone content | IANA functions (root zone management), published by the Root Zone Maintainer | — | Every root server instance | Operators serve the zone; they do not edit it. |
| Root server instance hosted in an operator’s network | The root server operator | Hosting operator’s data-centre / IXP team | — | The host provides space, power and connectivity; the root operator runs the server. |
| Recursive resolver service for customers | The ISP’s DNS platform (OSS) | — | Product catalog, where sold as a feature (filtering, security) | Outage here looks to customers like “the internet is down”. |
In practice
Most operators touch subsea cables through contracts, not engineering: a capacity team buys IRUs or leases on several systems, and the NOC routes over them. Large international carriers also hold consortium seats and landing licences. Hosting a root or TLD instance is a request an operator or internet exchange makes to a root server operator; it keeps lookups local and working when international links fail.
The trade-off
What it solves
It explains the dependencies outside the operator’s network that its services still rely on — international capacity and the naming system — and where they show up in BSS and OSS: wholesale contracts, resource inventory, resolver platforms and cross-owner trouble tickets.
What it does not solve
- Which cable a given customer’s traffic uses. Routing decides that and changes it.
- Exact cable routes. Public route maps are drawings; the exact positions are the owners’.
What it adds
- A cable fault is a trouble ticket that crosses several owners, repair ships and regulators, with restoration measured in days or weeks.
- Real diversity needs physical-path data (landings, straits, backhaul) that commercial capacity records rarely hold.
Architecture decision
How should an operator secure international capacity?
Buy IRUs on several systems
Choose when traffic is large and predictable enough to justify long-term commitments, and the systems take genuinely different paths.
Join a consortium
Choose when the operator needs a landing in its own country, has the traffic to fill fibre pairs, and can carry a share of build and maintenance for the cable’s life.
Lease wavelengths or circuits
Choose when demand is small, uncertain or temporary, and flexibility matters more than unit cost.
Breaks if the “diverse” paths share a landing town, a backhaul route or a strait. One event takes them all out, and the contracts do not say so.
Takeaways
Key Takeaways
- Subsea fibre carries the overwhelming majority of intercontinental traffic; satellites a small share
- Cable systems are owned by consortia or privately, increasingly by hyperscalers; most operators buy capacity
- Thirteen root identities, twelve operators, about two thousand anycast instances
- Root servers are not resolvers: public DNS services like 8.8.8.8 are recursive resolvers
- Nothing ties a DNS lookup to a particular cable; routing decides the path
Check yourself
Why are there only thirteen root server names but about two thousand root server instances?Show answerHide
Each name is one address served from many places by anycast: every instance announces the same address in routing, and each query reaches the nearest. The number of names is fixed; the number of instances grows wherever operators deploy more.
An operator has capacity on two subsea systems and both fail in one event. What went wrong in the design?Show answerHide
The paths were commercially separate but not physically diverse: they shared a landing town, a backhaul route or a strait. Diversity has to be checked on physical paths, not on contracts.