RIPE database objects every resource holder should understand

The RIPE Database is the public record of who holds which IP addresses and AS numbers in the RIPE region, who to contact about them, and who may change them. If you hold resources, a handful of object types decide how your network is identified, routed and protected. This guide explains what each one is for and what to check on yours.

Resource objects: inetnum, inet6num and aut-num

These objects describe the resources themselves.

An inetnum object registers a range of IPv4 addresses, and an inet6num does the same for an IPv6 prefix. Key attributes include netname:, country:, org:, admin-c:, tech-c:, mnt-by: and status:. The status tells you what kind of resource it is: for example ALLOCATED PA for an LIR’s allocation, ASSIGNED PA for an assignment made from one, ASSIGNED PI for provider independent space, or LEGACY for space that predates the RIPE NCC. IPv6 uses its own values, such as ALLOCATED-BY-RIR, ASSIGNED and AGGREGATED-BY-LIR.

An aut-num object registers an Autonomous System Number. Alongside contacts and maintainers, it can carry import: and export: lines (mp-import: and mp-export: for IPv6) that describe your routing policy in RPSL. These are optional, but some operators read them, and a tidy aut-num signals a maintained network.

For independent resources, the sponsoring-org: attribute shows which LIR sponsors them.

What to check: org: points to your current organisation, the contacts are valid, and every maintainer listed is one you recognise.

Routing objects: route and route6

A route (IPv4) or route6 (IPv6) object pairs a prefix with the AS number allowed to originate it. It is an entry in the Internet Routing Registry stating that this prefix may be announced by this AS.

Many transit providers and internet exchange route servers build their BGP filters from IRR data, often with tools such as bgpq4. If the route object is missing or names the wrong origin, your announcement may be filtered even when everything else is right.

Creating a route object needs authorisation from the maintainers of the address space, typically through mnt-routes:, mnt-lower: or mnt-by: on the covering inetnum. On leased space, that’s why the holder either creates the object for you or adds your maintainer.

Two related objects are worth knowing. An as-set lists the ASNs behind yours, such as customers, and upstreams use it to decide which routes to accept from you. A route-set groups prefixes.

Route objects and RPKI ROAs do similar jobs in different systems. Keep both aligned with what you actually announce, and remove stale entries when an origin changes.

Access control: mntner

A mntner (maintainer) object controls who can create, modify or delete other objects. Every object you care about has an mnt-by: attribute pointing to a maintainer, and the maintainer’s auth: lines define how someone proves they’re allowed to act.

Good practice:

• Use authentication tied to individual people, such as RIPE NCC Access (SSO) accounts or PGP keys, rather than a shared password.
• Remove access for staff and contractors who have left.
• Point upd-to: at a mailbox someone reads, so failed update attempts get noticed.
• Know the delegating attributes: mnt-lower: protects more specific objects, mnt-routes: controls route objects, and mnt-domains: controls reverse DNS.

If a third party’s maintainer appears on your objects, find out why. It’s often a leftover from a previous provider or sponsor.

Identity and contacts: organisation, role and person

The organisation object identifies the legal entity behind your resources, and resource objects point to it through org:. It holds the name, address and an abuse-c: reference. For organisations holding RIPE NCC-issued resources, the legal name is protected and changed through the RIPE NCC or your sponsoring LIR, so it should match your company documents.

A role object describes a team rather than an individual, such as a NOC or abuse desk. It is the better choice for admin-c: and tech-c: because it survives staff changes. Your abuse contact must be a role object with an abuse-mailbox: attribute, and the RIPE NCC periodically validates that address, so it has to be real and monitored.

A person object describes an individual. Its contents are publicly visible personal data, so keep person objects to a minimum, use business contact details, and delete those that no longer apply.

What to check: no former employees listed as contacts, and an abuse mailbox that reaches someone who acts on it.

Reverse DNS: domain objects

A domain object delegates a reverse DNS zone to the nameservers listed in its nserver: lines. For IPv4 that’s a zone such as 2.0.192.in-addr.arpa for a /24; for IPv6 it’s a nibble-boundary zone under ip6.arpa. Those nameservers then answer PTR queries for your addresses, and an optional ds-rdata: attribute adds DNSSEC.

The RIPE NCC runs technical checks on the listed nameservers before accepting a delegation, so set up and test the zone first. Authorisation comes from the address space’s maintainers through mnt-domains:, mnt-lower: or mnt-by:.

Reverse DNS affects mail delivery and some cloud BYOIP validation steps, so a missing or broken domain object can cause problems well beyond DNS itself.

How TACS can help

TACS maintains RIPE Database objects for the resources we sponsor and manage, and can review yours for stale contacts, unexpected maintainers and missing route or domain objects. See our LIR services, or BYOIP if you’re preparing objects for a cloud provider.