All posts

ASN Lookups Explained: What RDAP Returns Across the Five Registries

April 24, 2026

Cloudflare is AS13335. Google is AS15169. Deutsche Telekom is AS3320. Every network that announces its own IP space to BGP peers has a number like one of these. RDAP is the protocol that turns the number into a registration record: who runs the network, where they are, and how to reach the abuse desk.

If you work in security, network operations, or threat intelligence, the ASN is often more useful than the IP itself. Attack traffic from 203.0.113.45 is one host. Attack traffic from AS3320 is the entire footprint of Deutsche Telekom. The wrinkle: RDAP returns this data in different shapes depending on which of the five regional registries assigned the ASN.

What an ASN is

A 32-bit number (1 to 4,294,967,295) assigned by one of the five Regional Internet Registries: ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC. You get an ASN if you announce your own IP space to BGP peers. A small SaaS hosted on AWS does not; it lives inside Amazon's address space.

Three ranges are reserved. AS0 (RFC 7607), AS64512–AS65534, and AS4200000000–AS4294967294 (RFC 6996) are private, like 10.0.0.0/8 for IPs. RDAP returns nothing for any of them.

Looking up an ASN with raw RDAP

The IANA bootstrap registry at https://data.iana.org/rdap/asn.json maps ASN ranges to the right RIR. AS13335 falls in the ARIN range:

curl https://rdap.arin.net/registry/autnum/13335

The raw response (abbreviated):

{
  "objectClassName": "autnum",
  "handle": "AS13335",
  "name": "CLOUDFLARENET",
  "startAutnum": 13335,
  "endAutnum": 13335,
  "entities": [
    {
      "objectClassName": "entity",
      "handle": "CLOUD14",
      "roles": ["registrant"],
      "vcardArray": ["vcard", [
        ["version", {}, "text", "4.0"],
        ["fn", {}, "text", "Cloudflare, Inc."],
        ["adr", {"label": "101 Townsend Street\nSan Francisco\nCA\n94107"}, "text",
          ["", "", "", "", "", "", "US"]]
      ]]
    },
    {
      "handle": "ABUSE2916-ARIN",
      "roles": ["abuse"],
      "vcardArray": ["vcard", [
        ["fn", {}, "text", "Abuse"],
        ["email", {}, "text", "[email protected]"],
        ["tel", {"type": ["work", "voice"]}, "text", "+1-650-319-8930"]
      ]]
    }
  ]
}

The data you need is buried in the vcardArray of each entity. Find the entity with role "abuse", scan its vcardArray for the entry starting with "email", and pull element index 3. Repeat for the registrant. Repeat for the technical contact. Repeat for every ASN you query.

This is the same vcard shape covered in our IP ownership post: a contact format from 2011, plumbed into a JSON API.

The normalized response

Same query through our API:

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://rdapapi.io/api/v1/asn/13335

{
  "handle": "AS13335",
  "name": "CLOUDFLARENET",
  "type": null,
  "start_autnum": 13335,
  "end_autnum": 13335,
  "country": null,
  "status": ["active"],
  "dates": {
    "registered": "2010-07-14T18:35:57-04:00",
    "expires": null,
    "updated": "2017-02-17T18:04:32-05:00"
  },
  "entities": {
    "registrant": {
      "handle": "CLOUD14",
      "name": "Cloudflare, Inc.",
      "address": "101 Townsend Street\nSan Francisco\nCA\n94107\nUnited States"
    },
    "abuse": {
      "handle": "ABUSE2916-ARIN",
      "name": "Abuse",
      "email": "[email protected]",
      "phone": "+16503198930"
    }
  },
  "remarks": [
    {
      "title": "Registration Comments",
      "description": "All Cloudflare abuse reporting can be done via https://www.cloudflare.com/abuse"
    }
  ],
  "port43": "whois.arin.net"
}

The fields worth pausing on:

  • name is a short network handle assigned by the RIR (GOOGLE, DTAG for Deutsche Telekom, CHINA169-Backbone). The full legal name is usually in entities.registrant.name, though RIPE responses sometimes carry a maintainer handle there instead.
  • start_autnum and end_autnum are usually equal: most ASN registrations are a single number, not a range.
  • country is null in every autnum response we have inspected: 74 ASNs across all five RIRs. RIRs put country information on IP records, not on ASNs. Do not rely on this field.
  • status is typically ["active"]. Reserved or revoked ASNs may show different values.
  • port43 is the legacy WHOIS server URL, useful as a giveaway of which RIR served the response: whois.arin.net, whois.ripe.net, whois.apnic.net, whois.lacnic.net, or whois.afrinic.net.

Same endpoint, different conventions

Same protocol, same JSON envelope, different conventions for what goes inside. Three contrasts below cover the patterns you are most likely to hit; LACNIC and AFRINIC are similar enough to RIPE that the same parsing approach works.

RIPE NCC (AS3320, Deutsche Telekom):

{
  "handle": "AS3320",
  "name": "DTAG",
  "dates": {
    "registered": "1970-01-01T00:00:00Z",
    "updated": "2020-12-11T15:33:02Z"
  },
  "entities": {
    "registrant": {
      "handle": "RIPE-NCC-END-MNT",
      "name": "RIPE-NCC-END-MNT",
      "organization": "ORG-NCC1-RIPE"
    },
    "abuse": {
      "name": "Deutsche Telekom LIR Abuse Contact",
      "email": "[email protected]"
    },
    "administrative": {
      "name": "Sebastian Becker",
      "phone": "+4922818123797"
    }
  }
}

The registration date is the Unix epoch, 1970-01-01. RIPE assigned AS3320 to Deutsche Telekom long before the registry started tracking assignment dates, and rather than fabricate a date, RIPE returns zero. Many older European ASNs return the same epoch.

The registrant is also unusual: it is a maintainer object (RIPE-NCC-END-MNT), not the operator. The operator's actual name is under administrative or technical, often as a named individual. RIPE expects named technical contacts. ARIN does not. Same protocol, opposite norms.

APNIC (AS4837, China Unicom):

{
  "handle": "AS4837",
  "name": "CHINA169-Backbone",
  "entities": {
    "abuse": {
      "handle": "IRT-CU-CN",
      "email": "[email protected]"
    },
    "technical": {
      "handle": "CH444-AP",
      "name": "CNCGroup Hostmaster",
      "email": "[email protected]",
      "phone": "+861066259764"
    }
  }
}

APNIC populates an Incident Response Team (IRT) handle for the abuse role. It looks like a formal team contact, but the email behind it ([email protected]) points at one engineer rather than a team alias. There is no registrant entity for this ASN at all; the operator metadata is under technical.

ARIN without an abuse contact (AS15169, Google):

{
  "handle": "AS15169",
  "name": "GOOGLE",
  "entities": {
    "registrant": {
      "name": "Google LLC",
      "address": "1600 Amphitheatre Parkway\nMountain View\nCA\n94043\nUnited States"
    },
    "technical": {
      "handle": "ZG39-ARIN",
      "name": "Google LLC",
      "email": "[email protected]",
      "phone": "+16502530000"
    }
  }
}

No abuse entity. ARIN requires abuse contacts on IP allocations, not on ASNs. To report abuse for traffic from AS15169, look up the specific IP block instead.

So across these four examples (Cloudflare, Deutsche Telekom, China Unicom, Google), entities.abuse.email is present in three and absent in one. Code that calls this endpoint must handle the missing field.

Practical use cases

Picking the right abuse contact

A workflow that handles the missing abuse case:

import os
from rdapapi import RdapApi

api = RdapApi(os.environ["RDAP_API_KEY"])

def find_contact(asn):
    record = api.asn(asn)

    if record.entities.abuse and record.entities.abuse.email:
        return ("abuse", record.entities.abuse.email)

    if record.entities.technical and record.entities.technical.email:
        return ("technical", record.entities.technical.email)

    return (None, None)

print(find_contact(13335))  # ('abuse', '[email protected]')
print(find_contact(15169))  # ('technical', '[email protected]')
print(find_contact(4837))   # ('abuse', '[email protected]')

The role tag matters because a RIPE technical contact is often a named individual whose inbox is not designed for unsolicited abuse reports. The downstream system reading the email needs to know whether it is talking to a real abuse desk or to a person listed as on-call.

Adding ASN context to security alerts

If you have an indicator like 203.0.113.45 attempted SSH brute force, the useful enrichment is the ASN that owns it. That gives you context across logs: when many IPs share an ASN, the source is often a single actor or a single compromised network.

The catch: RDAP does not map IPs to ASNs. RDAP autnum lookups go from ASN to organization. The IP-to-ASN mapping is a BGP problem, not an RDAP one. The usual flow is:

  1. Take the IP, find its ASN through BGP data.
  2. Look up the ASN with RDAP for operator details.
  3. Look up the IP block with RDAP for the per-block abuse contact.

Steps 2 and 3 are RDAP. Step 1 needs a separate routing data source.

What RDAP autnum will not tell you

  • Which IP prefixes the ASN announces, or who it peers with. Routing and peering are BGP, not RDAP.
  • Traffic volume, customer count, or business size. None of this is in any RDAP record.
  • Whether the ASN is currently routed. An ASN can exist in the registry and announce nothing in BGP. RDAP will happily return it as active regardless.
  • Sub-allocations. A large ISP might carry traffic for thousands of downstream customers under one ASN. RDAP autnum tells you about the ISP. To reach the customer, query the IP block.

Try it

Look up any ASN in our web lookup, free and no account needed. For programmatic access, grab an API key and call /api/v1/asn/{asn}. The endpoint accepts 13335 and AS13335 interchangeably.

For the matching IP-block lookup, our IP ownership guide walks through what /api/v1/ip/{ip} returns and where the abuse contact comes from.

Ready to try RDAP lookups?

Get your API keyTry a free lookup