Intermediate · IRR, RPSL and AS-SETs · section 2 of 8

Routing registries and whois

✓ Lab-tested 17 October 2026 on IRRd 4.5.3, bgpq4 1.9, PostgreSQL 16, Redis 7

An Internet Routing Registry (IRR) is a database of routing information: which AS originates which prefix, which ASes are grouped together, and who maintains each record. There are many IRRs, and they mirror each other.

Kind	Examples	Who can register a route
Authoritative: run by a Regional Internet Registry	RIPE, APNIC, AFRINIC, LACNIC, ARIN	Only the holder of the address space, for space that RIR manages
Non-authoritative: run by third parties	RADb, ALTDB, NTTCOM	Any account holder, for any space: the data isn't checked against who holds it

Non-authoritative IRRs exist for historical reasons and still matter. Plenty of legacy registrations live only there. But it means an object in RADb proves nothing by itself. Prefer authoritative sources, and know which ones your tooling trusts. (RIPE's RIPE-NONAUTH source holds old objects for space RIPE doesn't manage; it is non-authoritative despite the name.)

Querying

IRRs speak the whois protocol: a plain-text query over TCP port 43 (RFC 3912). The whois command just opens the connection and prints the reply. RIPE's server supports flags such as -i (inverse lookup by an attribute), -T (object types) and -r (don't return contact objects).

Servers running IRRd, the software behind RADb and many others, also accept short machine-friendly queries starting with !. Filter-building tools use these. A reply is A<length> followed by the data and C; D means there's nothing to return.

For registration data about people and organisations, RIRs also offer RDAP, a JSON-over-HTTPS successor to whois. Routing tools still use whois and IRRd queries.

Diagram: Where IRR data comes from and where it goes — How a customer's registration becomes your router's filter.

The customer registers its data. AS64501 creates route objects for its prefixes and an AS-SET listing its customers, in the database of the RIR that allocated its space. The RIR checks that the maintainer controls the address space.
IRRs mirror each other. RADb and other IRRs continuously mirror the RIR databases (via the NRTM protocol), so one query can see objects from many sources. They also hold their own objects, which nobody verified against the address registry.
You expand the AS-SET. Your tooling asks the IRR to expand AS64501:AS-CUSTOMERS to its ASNs, then fetches every route object originated by those ASNs. bgpq4 does both in one command.
Filters reach the routers. The generated prefix-list is pushed to the edge router, typically daily or every few hours. When the customer registers a new prefix, your filter updates automatically, with no ticket needed.

Common IRR queries

# Any object, by its primary key
whois -h whois.ripe.net AS64500

# Every route object with origin AS64500 (an inverse lookup)
whois -h whois.ripe.net -i origin AS64500

# Only route/route6 objects, without the contact objects
whois -h whois.ripe.net -r -T route,route6 -i origin AS64500

# The registration covering an address: inetnum, route and contacts
whois -h whois.ripe.net 198.51.100.10

# IRRd servers (RADb and others) also accept short "!" queries
echo '!gAS64500' | nc whois.radb.net 43
echo '!6AS64500' | nc whois.radb.net 43
echo '!iAS64500:AS-CUSTOMERS,1' | nc whois.radb.net 43

Line 2: Look up any object by its primary key: an ASN returns the aut-num, a set name returns the as-set.
Line 5: -i origin is an inverse lookup: every object whose origin: attribute is AS64500. The quickest way to see what an AS has registered.
Line 8: -T restricts object types and -r skips the person/role objects normally returned with them. Use this in scripts.
Line 11: Querying an address returns the most specific registration covering it, plus its route object. Useful when investigating a suspicious announcement.
Lines 14–15: IRRd queries: !g lists IPv4 prefixes originated by an AS, !6 the IPv6 ones. This is what bgpq4 sends.
Line 16: !i expands a set; ,1 means recursively, flattening nested sets to plain ASNs.

IRRd replies (real output from the lab's local IRRd)

$ echo '!gAS64500' | nc irrd 43
A16
198.51.100.0/24
C
$ echo '!6AS64500' | nc irrd 43
A18
2001:db8:500::/48
C
$ echo '!iAS64500:AS-CUSTOMERS,1' | nc irrd 43
A40
AS64500 AS64501 AS64502 AS64503 AS64504
C
$ echo '!gAS64511' | nc irrd 43
D

Lines 2–4: A16: 16 bytes of data follow (including the newline), then C for success.
Lines 6–7: !6: the IPv6 equivalent, from the route6 object.
Lines 10–12: The flattened set: every ASN in AS64500's cone. AS64504 is only there because its aut-num says member-of: AS64500:AS-CUSTOMERS and is maintained by EXAMPLE-MNT, which the set's mbrs-by-ref allows.
Line 14: D: nothing found. An AS with no route objects, or a set that doesn't exist, looks like this.

An inverse lookup (real output from the lab's local IRRd)

$ whois -h irrd -r -T route,route6 -i origin AS64500
Warning: RIPE flags used with a traditional server.
route:          198.51.100.0/24
descr:          Example Network
origin:         AS64500
mnt-by:         EXAMPLE-MNT
source:         RIPE
rpki-ov-state:  not_found # No ROAs found, or RPKI validation not enabled for source

route6:         2001:db8:500::/48
origin:         AS64500
mnt-by:         EXAMPLE-MNT
source:         RIPE
rpki-ov-state:  not_found # No ROAs found, or RPKI validation not enabled for source

Line 2: The standard whois client warns when RIPE-style flags go to a non-RIPE server. IRRd understands them anyway.
Lines 3–7: Every route object with origin: AS64500…
Line 8: …with IRRd's own annotation: route objects can be checked against RPKI (the next lesson). This lab has no RPKI data.
Lines 10–14: …and the route6 object.

Check your understanding

You find a route object for 203.0.113.0/24 with origin AS64511 in RADb. What does it prove?

That AS64511 holds 203.0.113.0/24
Only that someone with a RADb account created it
That the RIR approved AS64511's announcement
That AS64511 is currently announcing the prefix