JSON Responses for the Registration Data Access Protocol (RDAP)
Extracted elements (30)
All entity types — organizations, corporations, governments, non-profits, individuals, and informal groups — are represented using a single entity object class. This design aids code reuse by implementers, as the information structures are so similar across entity types.
Internationalized Domain Names (IDNs) returned in URIs within link objects SHOULD be consistently returned in LDH name format to allow clients to process these IDNs according to their own capabilities.
All JSON names specified in this document are case sensitive. Both servers and clients MUST transmit and process them using the specified character case.
An objectClassName is REQUIRED in all RDAP response objects so that the type of the object can be interpreted.
Clients of these JSON responses SHOULD ignore unrecognized JSON members in responses. Servers that insert unspecified members SHOULD have member names prefixed with a short identifier followed by an underscore.
Clients using self links for caching SHOULD NOT cache any object class instances where the authority of the self link is different than the authority of the server returning the data, to prevent cache poisoning.
For every object class instance in a response, servers SHOULD provide a link representing a URI for that object class instance using the "self" relationship.
In link objects, the "value", "rel", and "href" JSON values MUST be specified. A "related" link relation MUST NOT include an "href" URI that is the same as the "self" link relation href to reduce the risk of infinite client processing loops.
In notices and remarks objects, the "description" array MUST be included; all other JSON values are OPTIONAL.
Self links MUST contain a "type" element with the value "application/rdap+json" when referencing RDAP object instances. Clients MUST be able to process object instances without a self link.
The rdapConformance data structure MUST appear in the topmost JSON object of a response and MUST NOT appear anywhere else.
When custom JSON values are inserted into responses, conformance to those specifications MUST be indicated by including a unique string literal registered in the IANA RDAP Extensions registry.
RDAP servers may redact, obscure, or omit registration data based on authorization level; registered status values "removed", "obscured", and "private" explicitly signal data suppression on entity objects. Truncation notices allow servers to communicate the reason for omitted data (authorization, load, or unexplainable).
Error responses contain a REQUIRED numeric "errorCode" (corresponding to the HTTP status code), an OPTIONAL "title" string, and an OPTIONAL "description" array of strings. The rdapConformance and notices structures may also be included.
Search responses wrap arrays of object instances in named members: "domainSearchResults" for /domains, "nameserverSearchResults" for /nameservers, and "entitySearchResults" for /entities queries.
The Autonomous System number (autnum) object class models AS number registrations for RIRs, with startAutnum and endAutnum as unsigned 32-bit integers (per RFC 5396), plus name, type, country, status, and entities.
The domain object class represents a DNS name and delegation point, containing nameservers, secureDNS (with dsData and keyData arrays), variants for IDN tables, entities, and status. It is used for both forward DNS (DNRs) and reverse DNS (RIRs).
The entity object class represents organizations, corporations, governments, non-profits, and individuals, using jCard (RFC 7095) for contact information. It is served by both RIRs and DNRs and supports embedded entities to model hierarchical relationships.
The events data structure is an array of objects, each with a REQUIRED "eventAction" string, a REQUIRED "eventDate" (RFC 3339 format), an OPTIONAL "eventActor", and OPTIONAL "links". Events may be future-dated (e.g., to indicate expiration).
The IP network object class models IP network registrations for RIRs, containing startAddress, endAddress, ipVersion ("v4" or "v6"), name, type (RIR-specific classification), country (ISO 3166 alpha-2), parentHandle, status, and entities.
The links array contains objects with members "value" (context URI), "rel", "href", and optionally "hreflang", "title", "media", and "type". Relationship types are defined by the IANA Link Relations registry per RFC 8288.
The nameserver object class represents DNS nameserver information, accommodating both first-class nameserver models (with handle, IP addresses, entities, events) and simplified embedded models containing only an ldhName.
The notices and remarks data structures are arrays of objects, each containing a "description" array, and optionally "title", "type" (registered remark/notice type), and "links". Notices describe the service or entire response; remarks describe the containing object class.
The rdapConformance data structure is an array of strings, each providing a hint as to the specifications used in the construction of the response. The string "rdap_level_0" signifies conformance with RFC 9083.
The secureDNS object within the domain class contains "zoneSigned" (boolean), "delegationSigned" (boolean), "maxSigLife" (integer, seconds), "dsData" (array with keyTag, algorithm, digest, digestType), and "keyData" (array with flags, protocol, algorithm, publicKey).
Truncated responses signal omitted data by including a typed notice (for truncated search result sets) or a typed remark (for truncated individual objects), using registered values such as "result set truncated due to authorization" or "object truncated due to authorization".
IANA maintains the "RDAP JSON Values" registry (under the "Registration Data Access Protocol (RDAP)" category) covering notice/remark types, status values, event actions, entity roles, and domain variant relations, operated under Expert Review policy.
IANA registers the "application/rdap+json" media type for use in RDAP responses. This media type is used in "type" fields of self links and HTTP Content-Type headers for RDAP responses.
As JSON is a subset of JavaScript, implementations are advised to follow RFC 8259 Section 12 security considerations to prevent code injection attacks when parsing RDAP JSON responses.
DNSSEC keys retrieved via RDAP are disconnected from their containing PKI because the RRSIG DS record from the parent zone is not conveyed. These keys are not generally expected to be trusted without additional information; the HTTPS channel protecting RDAP is not authorized to certify DNSSEC key validity.