Summary

  • Netnod AB's retained directory card rests on a single RIPE NCC member-directory URL entered twice, carries a confidence score of 0.82, and states in its own data gaps that the ASN and IP mapping must still be checked before anyone makes a routing claim about the company. The operator's own pages, captured on 29 October 2026, describe 200+ connected networks exchanging 3+ Tbps across seven Nordic locations and an I-root anycast service operated since 2000 — three surfaces the card does not describe and was never asked to.
  • If you are deciding whether to peer at the exchange, buy DNS service from the operator or write a resilience clause that names it, the question that decides your exposure is which autonomous system carries which surface. The retained evidence does not answer it: the I-root page excerpt carries ASN 8674, the exchange page carries ASN 213 only in a provider-written summary, and no registry record for either number was captured at this dateline. Treat the exchange and the root service as two failure domains until a routing record joins them.

Netnod AB is a Swedish Internet infrastructure operator. Its name appears in BTW's directory as an entity card, and the card is honest about itself in a way most records are not. Under data_gaps it asks, in plain terms, that someone verify the legal registration, the public website and the leadership contacts from official sources; that someone map the ASN and IP resources from RDAP, WHOIS, IRR, BGP or RIR delegation data before making any routing-footprint claim; and that nobody classify the company as an ISP, IP transit provider, cloud provider, registry or managed-network operator unless a current public source explicitly supports it.

That is a unusually self-aware piece of bookkeeping. It also marks exactly the boundary this article walks: the difference between a number-resource record and a running network. The record is not wrong. It is narrow, and it says so.

What the retained file actually contains

The card was created on 18 June 2026 and last updated the same day. It is titled Netnod AB, slug netnod-ab-se, entity type COMPANY, region SE, status PUBLISHED. Its source system is the RIPE NCC member directory, and its last import was performed by a member-directory import process.

Its evidence basis has two entries. The first is labelled "RIPE NCC member directory record" and supports the statement that Netnod AB appears in the RIPE NCC public member directory with registry-based country Sweden. The second is labelled "RIPE NCC member detail page" and supports a statement about member address, contact coverage and areas-serviced context. Both entries point at the same URL: the RIPE NCC member page for se/netnod (RIPE NCC member directory listing). Two labels, two described supports, one document.

Everything else in the card follows from that single document. It lists one resource row — resource type rir_membership, resource class virtual, country Sweden — and its known_role field says the company is listed in the member directory as a member registered or based in Sweden with official service-area context in Sweden. Its why_tracked field and its summary field both repeat the same constraint: this records a RIR member and resource-holder footprint and official service-area context, not proof that the entity sells ISP, IP transit, cloud, registry or managed-network services.

The confidence score is 0.82. That number measures how much confidence BTW has in its own record, not how good the company is. The relationships, inboundEdges, outboundEdges and unresolvedDirectoryLinks arrays are all empty. leadership_contacts, aliases and related_events are empty too. There is no website field. There is no ASN field. For a company whose entire public identity is a routing and DNS operation, the record holds no routing and no DNS.

That is not a scandal, and it is worth saying plainly why not. A member-directory import answers a narrow question: is this organisation a member of the registry, and in which country is it registered? It answers that question correctly. The card's authors then wrote down, in the record itself, every question the import could not answer. A reader who wants to know whether the company operates an exchange has to go somewhere else.

What the operator's own pages said

Somewhere else, on 29 October 2026, is four short retained excerpts. Each was captured from a public page and each carries a marker saying the text was reported back rather than read line by line. That distinction matters more than it usually does here, because some of the most quotable numbers sit outside the quoted text.

Start with the exchange. The excerpt from the operator's Internet Exchange page reads: "Netnod operates the largest Internet Exchange (IX) in the Nordics with 200+ networks exchanging 3+ Tbps of traffic... Netnod is the leading IX provider in the Nordic region... You can find us at seven different locations across the Nordic" (Netnod Internet Exchange page).

Three things are in that sentence and one is not. In it: a count of connected networks above 200, a traffic figure above 3 Tbps, and seven Nordic locations. That the exchange is the largest in the Nordics and that the company is the leading Nordic IX provider are the operator's own comparative claims, made on the operator's own page, and no independent ranking was captured to test them. What is not in the quoted text is an autonomous system number. ASN 213 appears only in the provider-written summary attached to the same capture, annotated as coming from an IX statistics snippet.

Next, the root server. The excerpt from the I-root page reads: "Since 2000, Netnod has operated i.root-servers.net, the first root server to be located outside of the United States... Netnod continuously expands the I-root anycast network... (ASN 8674)." (Netnod I-root page). Here the number is inside the quotation: ASN 8674 sits immediately after the sentence about expanding the anycast network. The figure of 80+ anycast locations, and the existence of a DNS slave service offered to TLDs, appear only in the provider-written summary, not in the quoted line.

Then ownership. The excerpt from the about page reads: "Netnod is a neutral and independent Internet infrastructure organisation based in Sweden. Netnod is fully owned by the non-profit foundation TU-stiftelsen (Stiftelsen för Telematikens utveckling)." (Netnod about page). The foundation ownership is quoted. The founding year of 1996, the Stockholm registered office and the Swedish registration number 556534-0014 appear only in the summary layer, and this article therefore does not assert them.

Finally the root-server index. Its quoted line is a statement about the system, not about Netnod: "The 13 root name servers are operated by 12 independent organisations." (Root Server Technical Operations Association operator index). That the index lists Netnod as the I-root operator is a summary-layer statement about the index, not a quoted line from it.

Read as one body of evidence, the four excerpts describe an operator with at least three distinct surfaces: a Nordic exchange with a stated participant count and a traffic figure, a root-server anycast service with a continuous operating history since 2000, and a non-profit foundation owner. None of those facts is in the directory card. All of them sit one fetch away from it.

Two routing identities, one unanswered question

The interesting problem is not that the record is thin. The interesting problem is that the four excerpts, read carefully, do not agree about which routing system carries which surface, and the one check that could have settled it did not complete.

The exchange page's quoted text names no ASN. Its summary layer offers 213. The I-root page's quoted text offers 8674, inside the quote. Both numbers are attached to the same company by the same retrieval generation. Neither is corroborated by a registry object captured in this run.

A registry-side check of both numbers was requested on 29 October 2026 at 13:16:10 and failed at the transport layer with the same permission error that had already terminated five earlier requests in this run, at 13:16:18. No registry record for either number was obtained. That failure is a fact about this article's evidence, not a fact about Netnod, and it is worth being precise about which of the two it is: nothing here shows that a registry record does not exist. It shows that at this dateline the article does not have one.

Why does that matter enough to write about? Because an exchange fabric and an anycast root service are not the same kind of network object, and the difference is the difference between two failure domains.

An exchange fabric is a shared Layer 2 environment in one or more physical sites. The operator runs it; the participants bring their own routers, their own ASNs and their own upstream relationships. If the fabric is announced under one ASN, that ASN's route policy, its upstreams and its looking-glass behaviour are part of your troubleshooting surface when sessions drop. An anycast root service is different: a set of service instances, each announcing the same destination prefix from wherever it is deployed, with the routing system choosing which instance answers a given resolver.

The operator's exposure there is to prefix origination, to the reachability of each instance and to the consistency of BGP announcements between them.

If both surfaces originate from one autonomous system, a single misconfiguration, a single upstream dispute or a single route-policy change can reach the exchange and the root service together. If they originate from two, they fail separately, and a resilience clause that names the operator should say which one it is buying. At this dateline the retained evidence points two ways and the article cannot resolve it. Anyone who needs the answer should ask for the origin AS of the exchange's looking-glass addresses and of the I-root instance prefixes, and get both in writing.

The gap is the ordinary distance, not a defect

There is a temptation to turn this into a story about a record that failed. That reading would be wrong, and the record itself argues against it.

A member-directory import is not an operator survey. It exists so that a registry can list its members and their registered country, and so that the wider community has a stable place to look up who holds what in the registry's own system. The import did that. It did not claim to describe an exchange, and the card explicitly forbids reading it as proof of any service classification. Where the card could have overreached — by inferring a service line from the company name, by adding an ASN from an unsourced memory, by folding a marketing claim into known_role — it did not.

The gap between what the card says and what the operator's pages say is the ordinary distance between a number-resource record and a running network. Records describe the resource; operators describe the service; only routing data and incident data describe the thing both of them are pointing at. Infrastructure readers get into trouble when they read one layer and believe they have read all three.

There is one more boundary worth drawing, because it is where articles like this usually go soft. The 3+ Tbps figure is a traffic description in an operator excerpt with no measurement date, no method and no port count. It is not average traffic, not capacity, not market share and not a claim about headroom. The 200+ figure counts connected networks; it says nothing about traffic symmetry, redundancy or customer concentration, and it must not be converted into a customer count or a revenue estimate.

Seven locations is a count without a site list, so no reader can tell from the retained evidence whether any two of them share power feeds, fibre routes or staff. The 80+ anycast locations are a summary-layer figure and say nothing about whether the instances are physically or routing-independent. And "neutral and independent" is the operator describing itself; only the foundation-ownership sentence is quoted, and the governance consequences of that ownership — board appointment, profit distribution, how neutrality is enforced — are not documented in the retained evidence.

BTW published a report on this operator on 30 July 2026 covering the exchange usage policy, the route server's separation of control plane from data path, and the I-root anycast history. That report answered a mechanism question. This one asks a different question — what the identity record underneath those mechanisms actually cites — and the answer is one registry URL, entered twice, with a confidence score of 0.82 and an explicit list of what is still missing.

That is a defensible finding, and it is a useful one. A reader who wanted to know whether Netnod runs an exchange now knows which of BTW's records does not say so, and which operator page does. A reader who wanted to know whether the exchange and the root service fail together knows the question is open and knows exactly which two numbers are in dispute. A reader who wanted a single confident verdict on the company's routing identity will have to wait for a registry record — or ask the operator.

Sources