How to Read an ASN RDAP Response

An Autonomous System Number RDAP response describes an ASN registration maintained by a Regional Internet Registry. It can identify the number or range that matched the query, the record’s holder-assigned name and registry-specific classification, associated organizations and contacts, and registration events and statuses.

It does not show which prefixes the ASN currently originates, which networks it peers with, whether a route is valid under RPKI, or who generated traffic that passed through the autonomous system.

This guide focuses on the RDAP autnum object. For address allocations, CIDR blocks and RIR hierarchy, use the separate guide to reading an IP address RDAP response. To retrieve the JSON from a terminal first, see how to query an RDAP server with cURL.

Quick answer: Confirm that objectClassName is autnum, then check whether the queried ASN falls between startAutnum and endAutnum. Use handle as the registry identifier, name as a holder-assigned label, and type and country as registry-specific metadata. Use entities with their roles to find associated organizations and contacts. Treat status and events as registration metadata. Use separate BGP and RPKI sources for current routing and route-origin authorization.

The fields to check first

Question	Field or section
What kind of object was returned?	objectClassName
Which ASN or registered block matched?	startAutnum and endAutnum
What identifies the record?	handle and name
How does the RIR classify it?	type
Which country code is associated with it?	country, when supplied
What is the registration state?	status
Which organizations and contacts are associated?	entities and roles
When did the registry record change?	events
What qualifications apply?	notices, remarks and rdapConformance

Except for objectClassName, the base RDAP specification permits registration-data members to be omitted under server policy. The NRO RDAP profile used by RIR services applies stronger requirements to several core fields, but clients should still tolerate omissions, implementation differences, redirects and responses from delegated services.

A simplified ASN response

The following example is illustrative and intentionally shortened. It uses AS64496, which belongs to a block reserved by RFC 5398 for documentation, together with fictional identifiers and contact details.

{
  "rdapConformance": [
    "rdap_level_0"
  ],
  "objectClassName": "autnum",
  "handle": "AS64496-EXAMPLE",
  "startAutnum": 64496,
  "endAutnum": 64496,
  "name": "EXAMPLE-AS",
  "type": "DOCUMENTATION",
  "status": [
    "reserved"
  ],
  "entities": [
    {
      "objectClassName": "entity",
      "handle": "ORG-EXAMPLE",
      "roles": ["registrant"],
      "vcardArray": [
        "vcard",
        [
          ["version", {}, "text", "4.0"],
          ["fn", {}, "text", "Example Network Operator"]
        ]
      ],
      "entities": [
        {
          "objectClassName": "entity",
          "handle": "ABUSE-EXAMPLE",
          "roles": ["abuse"],
          "vcardArray": [
            "vcard",
            [
              ["version", {}, "text", "4.0"],
              ["fn", {}, "text", "Abuse Desk"],
              ["email", {}, "text", "abuse@example.test"]
            ]
          ]
        }
      ]
    }
  ],
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "2020-01-15T00:00:00Z"
    },
    {
      "eventAction": "last changed",
      "eventDate": "2026-06-10T12:30:00Z"
    }
  ],
  "links": [
    {
      "value": "https://rdap.example.test/autnum/64496",
      "rel": "self",
      "href": "https://rdap.example.test/autnum/64496",
      "type": "application/rdap+json"
    }
  ]
}

The response says that the query matched a registration whose inclusive range begins and ends at 64496. It associates an example registrant and a nested abuse contact with the record. Because this ASN is reserved for documentation, the illustrative status is reserved, not active.

Why RDAP calls the object autnum

RDAP uses autnum as the object-class and query-path name for an Autonomous System number. A successful exact lookup normally uses this path:

autnum/{autonomous system number}

The path takes the ASN in asplain notation: one decimal integer without an AS prefix. A lookup for AS15169, for example, uses:

autnum/15169

The AS prefix remains common in prose, search boxes and routing tools, but it is not part of the standardized RDAP path. RDAP Lookup accepts either form and normalizes it before constructing the request.

Older tools can display four-byte ASNs using asdot notation. For example, decimal ASN 65546 can appear as 1.10. RDAP queries use its asplain value:

autnum/65546

Do not send autnum/AS65546 or autnum/1.10. Convert the value to its decimal representation first. RFC 5396 defines asplain as the standard textual representation for AS numbers.

Confirm the object type and source

Start with objectClassName. For an ASN registration, the top-level value should be:

"objectClassName": "autnum"

This distinguishes the response from an IP network, domain, nameserver or entity object and tells a parser which object-specific members to expect.

Next, record the service that supplied the response. RDAP clients find an ASN service through IANA’s ASN bootstrap registry. Its entries map inclusive ASN ranges to one or more base RDAP URLs. The client finds the range containing the requested number and appends autnum/{number} to a selected base URL.

The bootstrap range is a routing instruction for the RDAP request. It is not necessarily the same as the startAutnum and endAutnum range in the returned registration. Preserve the bootstrap result, redirects, final response URL and retrieval time as provenance. Retain a self link when present, but verify that its authority is consistent with the responding service before treating it as canonical.

Read startAutnum and endAutnum as an inclusive range

The two autnum-specific numeric members are:

• startAutnum: the first ASN in the registered block
• endAutnum: the last ASN in the registered block

Both are unsigned 32-bit integers in the RDAP data model. Verify that the ASN you queried falls inclusively between them.

For an individual registration, the two values are normally equal:

{
  "startAutnum": 15169,
  "endAutnum": 15169
}

RDAP also supports block registrations:

{
  "startAutnum": 65536,
  "endAutnum": 65551
}

A range response does not mean every ASN in that range is currently assigned, visible in BGP or operated by one production network. It says that the registration service modeled the matching record as that block. Review its status, entities, remarks and profile behavior before inferring more.

The base specification permits optional fields to be absent, and live services can vary. A parser should not invent a missing boundary or silently replace it with the queried number. Display the values that were returned and identify omissions explicitly.

Interpret handle, name and type

These fields identify and classify the registration:

• handle is the RIR-unique identifier for the autnum record. It may look like AS15169, but its format is registry-specific and should not be parsed as a universal identifier.
• name is an identifier assigned to the registration by its holder. It can resemble an organization, network or service name, but it is a label rather than proof of legal identity.
• type is an RIR-specific classification based on that registry’s registration model. Values can describe an allocation or another local category.

Display type as supplied instead of forcing values from different RIRs into one universal enum. Use entity roles when identifying organizations; do not substitute name or handle for a registrant entity merely because they contain a recognizable brand.

Treat country as registration metadata

When present, country is a two-character country code attached to the autnum registration. It does not establish:

• where routers using the ASN are physically located;
• where the associated organization is incorporated;
• where traffic entered or left the network;
• the locations of users or services reached through the ASN; or
• which jurisdiction governs a particular event.

An autonomous system can operate infrastructure in many countries and announce anycast or globally distributed services. Interpret the field according to the returning RIR’s data model and policy, and use a separate source for questions about legal domicile or physical geography.

Identify organizations and contacts by role

The entities array contains organizations, groups or individuals associated with the ASN registration. Select them by their roles, never by array position.

Roles useful in an autnum response commonly include:

• registrant: the entity associated with the registration
• administrative: an administrative contact
• technical: a technical or operational contact
• abuse: the contact designated for abuse reports

Entities can contain more entities. A registrant organization may contain separate technical and abuse contacts, while another RIR can return those contacts directly in the top-level array. Traverse nested entities instead of examining only one level.

Contact details commonly use vcardArray, the jCard representation of vCard. Read properties by name, such as fn, org, email and tel, rather than relying on a fixed order. The domain guide explains how to read vcardArray in detail.

An abuse contact is a reporting destination, not an attribution result. Its presence does not prove that the contact generated, authorized or knew about traffic associated with the ASN. Follow the operator’s reporting instructions, include relevant timestamps and evidence, and disclose only the information needed to investigate the incident.

Read status as registration state

The status array describes the registry’s state for the autnum object. Under the NRO profile, commonly relevant values include:

• active: delegated for operational use or further delegation
• reserved: set aside in a special-purpose ASN registry
• administrative: an enclosing administrative delegation that is not itself marked active

An active registration does not prove that the ASN:

• is currently visible in BGP;
• originates any prefixes at this moment;
• has reachable routers or services;
• has a valid RPKI origin authorization for a particular prefix; or
• is responsible for traffic seen in a log.

Those are routing, authorization and attribution questions. Interpret every returned status, preserve unknown values, and consult the IANA RDAP JSON Values registry for registered definitions.

Read events as registry events

Each item in events combines an eventAction with an eventDate. Common actions include:

• registration: when the autnum object was registered in that system
• last changed: when its registration data last changed
• last update of RDAP database: when the service’s RDAP data was refreshed

These timestamps concern the registry record. They do not show when the ASN first appeared in BGP, when a route changed, when a peering session came up or when an incident occurred.

Select events by eventAction, not by array position. If evidence is time-sensitive, preserve both the event values and the time at which you retrieved the response.

Read notices, remarks, links and extensions

These sections qualify the result:

• notices apply to the service or complete response and can contain terms of use, rate limits and inaccuracy-reporting instructions.
• remarks apply to the object containing them and can explain registration policy, unusual fields, redaction or truncation.
• links connect the object to its own representation, related entities or alternate formats. Interpret them by rel and type.
• rdapConformance identifies the base specification and extensions used to construct the response.

For autnum query processing, the NRO profile defines two models and requires an implementing RIR to identify the selected model in rdapConformance:

• nro_rdap_profile_asn_flat_0 means that when the RIR has registration authority for an ASN but has not further delegated it to one of its accounts, the service returns 404 Not Found.
• nro_rdap_profile_asn_hierarchical_0 means that in the same situation, the service returns the most-specific administrative object that contains the ASN.

This difference matters when interpreting a range or a 404. The profile identifier explains how the service processes ASN queries; it does not describe whether a route is present in BGP.

Clients should ignore extension members they do not understand rather than reject the entire response. Do not assign meaning to an extension until you have identified its specification.

Registration is not routing

RDAP and BGP answer different questions:

Question	Appropriate source
Which RIR record covers this ASN?	RDAP
Which entities and contacts are associated with the registration?	RDAP
Which prefixes is the ASN currently originating?	Current BGP data
What AS path was observed for a prefix?	BGP route collectors or local routing data
Is the ASN authorized to originate a prefix under RPKI?	Validated RPKI data
What routing policy has an operator published?	An Internet Routing Registry, where applicable

The base autnum object has no standardized member listing currently originated prefixes, upstream providers, peers or customers. A recognizable ASN name and an active status cannot fill that gap.

BGP observations are also time- and vantage-point-dependent. A route collector can show what its peers observed, not every route at every point on the Internet. For an incident, use routing data covering the relevant time instead of substituting the latest available table.

Registration is not RPKI authorization

RPKI Route Origin Authorizations connect IP prefixes with ASNs that are authorized to originate them, subject to prefix-length constraints. An ASN RDAP record does not include the complete set of those authorizations and does not calculate Route Origin Validation state.

To evaluate a route, use validated RPKI data and compare the observed prefix and origin ASN with the relevant validated payloads. The result can be Valid, Invalid or NotFound under the origin-validation procedure. None of those states changes the fields in the ASN’s RDAP registration record.

RPKI origin validation is also not complete path validation. A route can have a valid origin while other questions about its propagation or AS path remain unresolved.

What an ASN RDAP response cannot tell you

An autnum response is registration evidence. On its own, it cannot establish:

• Currently announced prefixes. Use timestamped BGP data.
• The current origin of an IP prefix. Start with the prefix in BGP, then interpret the resulting ASN registration.
• Peers, upstreams or customers. These relationships require routing observations, operator data or other specialized sources.
• RPKI validity. Validate the observed route against current or historically appropriate RPKI data.
• Physical infrastructure location. The country field is not a router geolocation result.
• Who generated traffic. An ASN can contain many networks, customers, shared services and intermediaries.
• Legal ownership. Registration roles and labels do not by themselves establish legal title or organizational control.

For an investigation, correlate RDAP with timestamped packet or application logs, BGP observations, RPKI validation, IP-network registration data and information supplied by the relevant operator. Keep every source and retrieval time visible.

A practical reading order

Use this sequence when reviewing an ASN response:

1. Record the queried ASN, final RDAP URL and retrieval time.
2. Confirm objectClassName is autnum.
3. Verify the ASN falls between startAutnum and endAutnum when both are present.
4. Record the handle, name, type and country without treating labels as legal identity.
5. Traverse entities recursively and select them by role.
6. Read every status as registration state.
7. Read events by action and keep them separate from routing events.
8. Review notices, remarks, links and rdapConformance for qualifications.
9. Use BGP data for route visibility and path questions.
10. Use validated RPKI data for route-origin authorization.

This reduces a large response to four questions: Which registered ASN or block matched? Which entities are associated with it? What does the registry say about its state? Which routing claims still require another source?

Frequently asked questions

Does RDAP show who owns an ASN?

RDAP shows entities and contacts associated with an ASN registration. “Owner” can imply legal title, corporate identity or current operational control, none of which should be inferred from one field. Describe the entity by its returned role and preserve the RIR source.

Why did one ASN return a range?

RDAP permits registries to model AS numbers as individual registrations or blocks. If the queried number falls within a registered block, the response can identify that block through startAutnum and endAutnum.

Does active mean the ASN is announcing routes?

No. It describes registration state under the registry profile. Check current or historical BGP data to determine whether the ASN was observed originating prefixes.

Can an ASN lookup list all of its IP addresses?

Not through the base autnum object. ASNs and IP allocations are separate registrations, and a network can originate prefixes registered to different entities or allow another ASN to originate its space. Use routing data to identify observed prefixes, then inspect their IP RDAP records separately.

Can RDAP tell whether an ASN is malicious?

No. RDAP provides registration data and reporting contacts, not a reputation verdict. Abuse can originate from customers, compromised systems or short-lived infrastructure, and registration alone does not attribute conduct to every party associated with the ASN.

What is the difference between AS65546, 65546 and 1.10?

They can refer to the same numeric ASN in different contexts. AS65546 adds the conventional AS prefix, 65546 is asplain notation, and 1.10 is asdot notation. The standardized RDAP path uses the asplain value: autnum/65546.

Why can an ASN query return 404?

The service may have no matching registration, may use the NRO profile’s flat query model for an undelegated number, or may not be authoritative for the request. Confirm the ASN is valid, repeat IANA bootstrap discovery, follow safe redirects and inspect the RDAP error response before drawing a conclusion.

Read a live ASN response

Run an ASN lookup using a value such as AS15169, then compare the compact result with the raw RDAP JSON. Start with the returned number range and entities, and keep routing conclusions separate from the registration record.

The formal autnum object is defined in RFC 9083, ASN query behavior in RFC 9082, and service discovery in RFC 9224. RFC 5396 defines ASN textual notation, while the NRO RDAP profile documents common RIR response and query behavior.