Anchored Registry · data
Where this comes from, and what is left out on purpose
Every page in this directory is derived from files the RIPE NCC publishes openly. Below is exactly which files, exactly which fields are taken from them, and the fields that are never read at all. If your organisation is named on a page, there is a route to change or remove it.
The files
| Published by RIPE at | What is taken from it |
|---|---|
| ripe.db.aut-num.utf8.gz | AS numbers, their as-name and status, and the organisation handles that hold and sponsor them |
| ripe.db.inetnum.utf8.gz | IPv4 ranges, the same three fields, and the assignment status |
| ripe.db.inet6num.utf8.gz | IPv6 ranges, likewise |
| ripe.db.organisation.utf8.gz | one field: the published org-name for a handle, so a page can say a company's name instead of ORG-XX1-RIPE |
| pub/stats/*/delegated-extended | which of the five registries holds any given number, so a search can answer outside RIPE too |
No credentials are needed for any of them, and none of them carry personal data — RIPE removes it before publishing. Nothing here is queried through the database’s live interface at a rate a person could not.
What is published, in full
- The resource: an AS number or an address range, with the name and status the registry records for it.
- The organisation handle that holds it, and that organisation's published legal name.
- The organisation handle that sponsors it, and that organisation's published legal name.
- The country code on the record.
That is the whole list — 33,867 sponsored resources under 3,026 sponsoring organisations, and four facts about each. Every one of them is a fact about a resource, not about a person.
What is never read
- admin-c, tech-c, abuse-c
- e-mail and abuse-mailbox
- address, phone, fax-no
- person: and role: objects
- mnt-by and any authentication attribute
The dumps carry all of it. The importer does not parse those attributes, so no page here could print one even if it wanted to. The reason is the RIPE Database Terms and Conditions, which forbid using the database “for advertising, direct marketing, marketing research or similar purposes” — in any channel, not just in mail.
So this directory is an inbound channel by construction: nobody is ever written to because they appear in it. The pages exist so that a holder looking for their own resource finds us, and that is the only direction the contact runs. The single time a contact field is read at all is to check that a removal request under /removal comes from the organisation it claims to — which is the opposite of marketing, and it is never stored.
What it is for
Two questions that no other page answers: who sponsors a given resource, and what that relationship costs elsewhere. Both are operator coordination, and both are only answerable in the RIPE region, because RIPE is the one registry that publishes the sponsor at all. Anchored Registry is a RIPE NCC member and sponsors resources itself, so the directory is plainly not disinterested — which is the reason every figure on it is sourced and every page names where it came from.
Rebuilds, and the floor under the history
Pages are regenerated from the dumps, so a change made in the RIPE database arrives here on the next rebuild without anybody retyping it. That also means the fix for a wrong name or a wrong sponsor is in the registry rather than here. RIPE publishes no dated archive of its own database, so no history before 2026-08-21 is recoverable by anyone — pages say that instead of implying a resource never moved.
Removals survive rebuilds. They are held as a list of handles the importer filters out at the one point rows enter the site, so a page taken down does not reappear the next morning. Nobody has asked yet.
If something here is wrong
Corrections and removals — answered by a named person within one working day, the same promise the rest of this business runs on. The Acceptable Use Policy and the Terms and Conditions the data is read under are both short and worth the five minutes.